In this introductory course, we take a look at Spinnaker as a whole to understand what concepts Spinnaker excels at as a continuous delivery tool. We'll also touch upon the microservices architecture that makes Spinnaker a unique asset in your toolkit.
If you have any feedback relating to this course, feel free to reach out to us at email@example.com.
- Define Spinnaker at its most fundamental level
- Explain the two primary concepts that make Spinnaker a strong solution for continuous delivery:
- Application management
- Application deployment
- Explain the service architecture that makes up Spinnaker
- Anyone who is new to Spinnaker
- DevOps engineers and site reliability engineers
- Cloud-native developers
- Continuous delivery enthusiasts
To get the most out of this course you should possess:
- An understanding of continuous delivery and what it solves for
- A strong understanding of cloud concepts
- Kubernetes knowledge is advised
- Free Spinnaker eBook - https://spinnaker.io/docs/concepts/ebook/ContinuousDeliveryWithSpinnaker.pdf
- Spinnaker Website - Spinnaker.io
- Spinnaker Community - spinnakerteam.slack.com
- Spinnaker Lab - Spinnaker Lab
This is the last lecture on an introduction to Spinnaker. This lecture will cover a brief introduction to Spinnaker's microservices and their corresponding dependencies, as well as a look at the configuration tool for Spinnaker called Halyard.
Spinnaker relies on about eight services to accomplish its mission. These are the core services and this is just a preview of a future course to come, so the details will be surface level. You'll also notice that a lot of these names correspond to what they actually do, beginning with Deck, our browser-based UI. We've seen this throughout the course in our cluster paint overviews, and pipeline overviews.
Gate is our API gateway. All the other services depend on it either directly or indirectly. Orca is our orchestration engine. It is responsible for taking an execution definition in managing the stages and tasks, coordinating the other Spinnaker services.
Clouddriver, this service is the main integration point for Spinnaker cloud providers like AWS, GCE, Cloud Foundry, et cetera.
Front50, Front50 is the system of record for all Spinnaker metadata including application pipeline and service account configurations.
Roscoe, Roscoe bakes our images for the major cloud providers, and is exposed via RESTFUL API, and relies on packer.
Igor is a service that provides a single point of integration with continuous integration and source control management services for Spinnaker.
Echo is our router for events. For example, a new build is detected by Igor which should trigger a pipeline, and it is also a scheduler for CRON triggered pipelines.
Finally, we have Fiat. Fiat is the authorization server for the Spinnaker system. Is it exposed via a RESTful interface requiring the access permissions for a particular user or account.
These are the dependencies for Spinnaker services. If Gate doesn't start, well, it's probably a bad day because nothing's going to work. You will notice that Spinnaker considers Deck an external component. That's because it can run without a Spinnaker environment. And you'll also notice that there is a ran when configuring Spinnaker service called Halyard. This is the configuration tool recommended for deploying Spinnaker.
Let's talk about Halyard. Halyard is a custom Java tool built to manage the provisioning of all services associated with Spinnaker. It is the current recommended way for installing Spinnaker. And a successor to Halyard is being developed and is called Kleat, a lightweight tool written in Go. It is similar to Kubectl with its CLI syntax, hal deploy apply. And Halyard gets its name from the movie "2001:A Space Odyssey" in which a computer named HAL 9,000 causes issues for the main protagonist.
Let's close out the course, you're almost done. Check out the conclusion section for resources on getting started with Spinnaker now.
Introduction - What is Spinnaker? - How is Spinnaker Designed? Part One - How is Spinnaker Designed? Part Two - Conclusion
Jonathan Lewey is a DevOps Content Creator at Cloud Academy. With experience in the Networking and Operations of the traditional Information Technology industry, he has also lead the creation of applications for corporate integrations, and served as a Cloud Engineer supporting developer teams. Jonathan has a number of specialities including: a Cisco Certified Network Associate (R&S / Sec), an AWS Developer Associate, an AWS Solutions Architect, and is certified in Project Management.