Ethan Rogers, resident Spinnaker expert, explains how to use Spinnaker platform concepts to manage and deploy applications.
A Transcript of the video is available below:
Ethan: Hey guys I am Ethan, your Spinnaker expert. Thanks for joining us for another instalment of our Spinnaker training series where we teach you how to be effective and use Spinnaker. Today we are going to be talking about a number of concepts that you will find out throughout the platform and how to use them to manage and deploy your application. We will start at the bottom, work our way to the top, so that we have a solid foundation moving forward. At the base, we have a server group which is a single deployable factor than Spinnaker and contains basic configurations settings about your application such as the number of instances, the scaling policies and the resource requirement for application. We click on a server group represented by this large block in the UI, we can see a lot of information that is pertinent about the server group such as the capacity, the health and any scaling policies that we have attached. You can also see a bunch of different actions that we can take such as rollback, resize or clung.
Server groups are also vagant meaning that we can track the changes to our application on its deployed stage over the life cycle of our application and rollback to previously known good state if something were to go wrong. All server groups are rolled up under a cluster. A cluster is just a Logical grouping of server groups that define a specific environment. That environment could be test, stage or prod. Each version of the server group is represented under its respective cluster. Clusters are all rolled up under applications which give a specific simple point to manage the configuration of our application.
We can also define pipelines and pipelines are perhaps the bread and butter of Spinnaker. Pipelines are the main deployment component with Spinnaker and they make up a...they are made up of a sequence stages used to represent a deployment workflow by creating or modifying any of these clusters or server groups. They can be a simple or as complex as necessary. Pipelines are started at various stages without the...throughout the software development process such as pushing code to Github, a successful build by Jenkins or a new Docker image hitting your repository. Here we can see that we have a Jenkins job triggering this Spinnaker pipeline followed by a bake stage which takes the artifact produced by Jenkins and bakes into an AMI. The next step, we take that AMI and deploy it to a server group in AWS. Spinnaker provides all of these abstractions so that we have a common language when talking about deployments regardless the cloud provider that you are using. By giving everyone a common interface we can avoid having to re-invent the wheel for each new application or service being developed.
I hope today’s video has been helpful in expanding your understanding of Spinnaker and give you the confidence you need to deploy your next application. Thanks for watching.