stack is composed by a stack part and a config part (see Concept of a stack).
Our app is designed to easily manage the stacks content and configuration files through the Catalog Repository and Config Repository pages, with only need of providing SSH credentials and repository URLs.
# Designing a Stack
As explained above stacks concept is a way to organize Infrastructure as code files. Additionally to this concept, it is important to take time to define what should we put in a
The main recurrent interrogation from our customer is "How could I put my current application in a Cycloid stack?"
To this question, there is no unique answer. The
stack concept is really flexible and it will be up to the creator of the stack to define what it contains.
The three major points which lead how to design a stack are:
- Goal of the
stack: which service or application do we want to pack? And who will be the user of the stack?
- Application dependencies: what are the dependencies of my application from an infrastructure and a deployment point of view?
- Security/political restriction: are there any specific security rules or teams responsible for some resources?
Then the design of a
stack could impact it's:
- Reutilisability: if the stack is too specific it could be hard to reuse it in other projects
- Maintenance and complexity: the more the stack contains resources and use-cases, the harder it will be to maintain and update the infrastructure as code
Keeping the previous points in mind, let's now see two concrete examples of application and how could it be defined as
stacks. In addition, you can also read a bit more about Terraform recommended patterns (opens new window).
# Web application example
Here is a simple web application composed of compute instances on top of a network VPC.
One approach would be to create an entire standalone
stack. This stack will contain all resources to compose our application. Using infrastructure as code we will describe VPC network and compute instances.
This way each user of the
stack would be able to deploy a fully standalone web application. The stack will create for each user a dedicated VPC network and spawn the compute instances on top of it.
Now let's take a second approach and split this stack into two different ones. One dedicated to the network and one dedicated to instances.
This way your application is not anymore standalone but allows users to create a shared network using the
And deploy several instances using the
instance stack on this shared network.
Using the stack concept in Cycloid you will be able to link stacks together and let your users select the network previously created by the
network stack when they will deploy their application using the
In the case of shared responsibility across teams, the network team could create a network project on the Cycloid dashboard based on the
And the developer could deploy their applications with the
instance stack using the network created with the network project. And access to project limited using Cycloid role and policies management.
This approach could also be used and applied to any other components like object storages, databases, etc.
# Kubernetes example
At Cycloid we highly use and deploy containerized applications in Kubernetes. let's see how we do it using
If we simplify our workflow around Kubernetes, it could be seen as two use-cases:
- Create and manage the Kubernetes cluster
- Build container applications from application source code and deploy it on a Kubernetes cluster
To solve our needs we split them into two defined
- One to handle the infrastructure part: the creation of a Kubernetes cluster, access management, etc.
- And another one to define the entire application workflow: starting from the source code, going through our build process, and finally to the deployment on a Kubernetes cluster
On the Cycloid dashboard, we created a Kubernetes project based on our
infrastructure stack and an application based on our
This splitting method provides a way to manage our Kubernetes cluster and deploy as many applications as we want on top of it.
All this work can be found as part of our
public stacks. We provide different infrastructure stacks to create a Kubernetes cluster on different cloud providers:
- Scaleway Kapsule (opens new window)
- Azure AKS (opens new window)
- Google GKE (opens new window)
- Amazon EKS (opens new window)
Our application stack to build and deploy containers on Kubernetes cluster can also be found in our public stack called k8s-runner (opens new window).