As described in Part 1, deploying Atlassian software using AWS and Spinnaker offers some essential benefits. The second part is about how these can be deployed using YAML files. These contain the configuration of applications.
Deployment based on YAML files
Deployments are done in with YAML files that define the configuration of applications, services and more for Kubernetes. This should continue to include a name, a definition of what you want to deploy, and the number of replicas. For example, if we want to deploy a fail-save application on Kubernetes, we would use 2 components.
1. the application
First, the application itself. Since we want to make it fail-safe, we would deploy it in the form of a " replica set" with 3 replicas. Kubernetes then starts deploying 3 pods with the application described and distributes them to the compute nodes. This is done using hardware constraints and tags.
2. the service
The second component is a "service". You can think of it as a load balancer within the cluster. In addition, this service now takes care of load balancing on all our three pods. This is done based on certain tags that we specified in the deployment yaml. Depending on the service type, EKS can create an AWS load balancer with a public domain name. This allows us to access our application without manual network adjustments. Furthermore, it is also possible to deploy ingress controllers and make our application reachable with other tools.
Use of spinnaker
Anyone who has access to the cluster can now manually deploy applications. So we are developing a way to make all deployments transparent to everyone who works with them and to channel deployments through a standardized and reliable way.
This is where Spinnaker and its pipelines come into play. These give us an overview of the applications running in the cluster. It also allows us to easily get more in-depth information about deployments such as deployment versions, pipeline runs, or the status of the load balancer. Spinnaker itself is deployed to the cluster. As a result, Spinnaker benefits from the same resilience that Kubernetes provides for all applications under its control.
DevOps helps your company to deliver software solutions more efficiently and effectively and to convince your customers by constant updates. Learn more about DevOps.
Infrastructure from microservices
The idea here is to have an infrastructure that consists of containerized microservices. Each microservice/app is built from a dedicated repository and after changes are made, the application is built which is then used to build a new Docker image. This image is pushed to a private Docker registry.
This triggers a Spinnaker-pipeline, which now deploys the changed container with the deployed configuration as a new version to the cluster and changes the service load balancer so that it only routes traffic to the newly deployed version. If this version does not pass the built-in checks, the change is reversed and the old version is set active again via the service load balancer.
Ideally, the Spinnakers pipeline deploys all containers to a Dev/Stage environment first to check for errors before deploying the changes to the Master/Production environment. This allows a failed update to be rolled back automatically and also manually via the Spinnaker web UI.
Want to learn more about Atlassian Hosting on AWS? Go here to our cloud hosting services