{"__v":11,"_id":"56c14ca9f203270d00d6c546","api":{"auth":"required","params":[],"results":{"codes":[]},"settings":"","url":""},"body":"Spinnaker is an open source, multi-cloud continuous delivery platform that helps you release software changes with high velocity and confidence.\n\nIt provides two core sets of features: *cluster management* and *deployment management*. Here is an overview of these features:\n\n## Cluster Management\n\nYou use Spinnaker's cluster management features to manage the following resources in the cloud: \n\n* **Server Group**: The base resource, the *Server Group*, identifies the machine instance profile on which to execute images along with the number of instances. This resource is associated with a Load Balancer and a Security Group. A Server Group also has basic configuration settings, such as user account information and the region/zone in which images are deployed. When deployed, a Server Group is a collection of virtual machines running software.\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/4l9kTko1SVSIcI26iBSR_server_group.png\",\n        \"server_group.png\",\n        \"506\",\n        \"316\",\n        \"#c92933\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\n* **Security Group**: A *Security Group* defines network traffic access. It is effectively a set of firewall rules defined by an IP range (CIDR) along with a communication protocol (e.g., TCP) and port range.\n* **Load Balancer**: A *Load Balancer* is associated with an ingress protocol and port range. It balances traffic among instances in its Server Group. Optionally, you can enable health checks for a load balancer, with flexiblity to define health criteria and specify the health check endpoint.\n* **Cluster**: You can define *Clusters*, which are logical groupings of Server Groups in Spinnaker.\n\n## Deployment Management\n\nYou use Spinnaker's deployment management features to construct and manage continuous delivery workflows. These are some of the concepts associated with deployment management:\n\n* **Pipeline**: *Pipelines* are the key deployment management construct in Spinnaker. They consist of a sequence of actions, known as stages. You can pass parameters from stage to stage along the pipeline. You can start a pipeline manually, or you can configure it to be started by automatic triggers, such as a Jenkins job, a CRON schedule, or a stage in another pipeline. You can configure the pipeline to emit notifications to interested parties at various points during pipeline execution (such as on pipeline start/complete/fail), by email, SMS or HipChat.\n\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/Y1X8CO7KTkO7vO9x3ZZi_pipeline.png\",\n        \"pipeline.png\",\n        \"486\",\n        \"271\",\n        \"#4585c5\",\n        \"\"\n      ],\n      \"sizing\": \"smart\"\n    }\n  ]\n}\n[/block]\n* **Stage**: A *Stage* in Spinnaker is an action that forms a atomic building block for a pipeline. You can sequence stages in a Pipeline in any order, though some stage sequences may be more common than others. Spinnaker comes pre-packaged with a number of stages, including:\n  * **Bake**: Bakes an image in the specified region.\n\n    The purpose of baking is to create an immutable image that is typically used for the deploy step.  This step is powered by the Rosco service.  It’s primarily responsibility is to manage [Packer](https://www.packer.io/intro/) jobs and communicate status back to Orca.  This gives the Spinnaker operator the flexibility to create packer templates that are specific to their service team’s needs.  For Docker based deployments this is equivalent to the `docker build` command and is usually not needed for deployment\n\n    **Fields:**\n    *Regions*:  Where to bake the image.  When using a multi-region bake,  Rosco will launch multiple Packer jobs in each region.\n\n    *Package:* The package that will be passed to your packer template script.  Typically a deb or rpm package but can be any package that is an output of your build step.  **Note**: your Jenkins job will need to specify your package as an artifact.\n\n    *Base OS*: The base image or OS that you would like to use for the build step.  This can be configured in your `rosco.yml` property file if you need changes.\n\n    *VM Type (*[*AWS Specific*](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html)*):*  HVM or PV.  Make sure your instance type is compatible with the type of virtualization selected.   The C3 and M3 current generation instance types support PV AMIs. The C1, HI1, HS1, M1, M2, and T1 previous generation instance types support PV AMIs.\n\n    *Rebake:*  By default Spinnaker will not rebake your image if there are no changes to bake. This is typically based on the outputs of your Jenkins build but is cloud provider specific. More details can be found on how Rosco identifies duplicate bake requests [here](https://medium.com/continuous-delivery-scale/spinnaker-rosco-deduping-logic-e03716e04a30#.oelvxdd6s).\n\n    ***Advanced Options***\n    These are additional parameters that can be passed down to the packer templates you’ve created.  \n\n    *Template File Name:*  The packer template file to use for this bake step.  You’ll want want to place this on the disk along with the other default packer templates that are provided for you.  Typically here: `/opt/spinnaker/config` \n\n    *Extended Attributes:*  These are additional attributes defined by a user that are passed down to the Packer template.  These can be used in your packer JSON template file by using the variable like  `{{user 'name_of_ext_attr``'``}}` \n\n    *Var File Name:* The [packer variable file](https://www.packer.io/docs/templates/user-variables.html) to use.  This file must already exist on the file system.\n\n    *Base AMI or Image:* The image to use when baking if you need a custom image or a dynamic image that is found from an upstream `Find Image From Tags` step or something similar.\n\n    *AMI Name (AWS Specific):* The prefix of the image name that is used when the image is created and stored with the image registry.  The default is `$package-$arch-$ami_suffix-$store_type`  \n\n    *AMI Suffix (AWS Specific):* The suffix that is used after the AMI name.  String of date in format YYYYMMDDHHmm, default is calculated from timestamp.\n\n    *Enhanced Networking (AWS Specific):* This is whether to launch the bake instance with [enhanced networking](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html). This is AWS specific.\n\n  * **Deploy**: Deploys a previously baked or found image.\n  * **Destroy Server Group**: Destroys a server group.\n  * **Disable Server Group**: Disables a server group.\n  * **Enable Server Group**: Enables a server group.\n  * **Find Image**: Finds a previously-baked image to deploy into an existing cluster.\n  * **Jenkins**: Runs a Jenkins job.\n  * **Manual Judgment**: Waits for user approval before continuing.\n  * **Modify Scaling Process**: Suspend or resume server group scaling processes.\n  * **Pipeline**: Runs a pipeline. This allows you to compose pipelines hierarchically.\n  * **Quick Patch Server Group**: Quickly patches a server group (used for emergency patches).\n  * **Resize Server Group**: Resizes a server group.\n  * **Script**: Runs an arbitrary shell script.\n  * **Shrink Cluster**: Shrinks a cluster.\n  * **Wait**: Waits a specified period of time.","category":"55c6bec2b9aa4e0d0016c2c7","createdAt":"2016-02-15T03:57:29.648Z","excerpt":"","githubsync":"","hidden":false,"isReference":false,"link_external":false,"link_url":"","next":{"description":"","pages":[]},"order":0,"parentDoc":null,"project":"55c6bec1b9aa4e0d0016c2c3","slug":"overview","sync_unique":"","title":"Overview","type":"basic","updates":["5748b1b7919ad20e00b6c791","5862ddb983cbbf1900cf75a6","5862ddb95a47fe1900565da8","5862ddbaba46b22d003937ef","58b012a3d583072f009da235","58cefbcf3123c32d005f5398"],"user":"55c6b99c476be90d00500805","version":"55c6bec1b9aa4e0d0016c2c6","childrenPages":[]}
Spinnaker is an open source, multi-cloud continuous delivery platform that helps you release software changes with high velocity and confidence. It provides two core sets of features: *cluster management* and *deployment management*. Here is an overview of these features: ## Cluster Management You use Spinnaker's cluster management features to manage the following resources in the cloud: * **Server Group**: The base resource, the *Server Group*, identifies the machine instance profile on which to execute images along with the number of instances. This resource is associated with a Load Balancer and a Security Group. A Server Group also has basic configuration settings, such as user account information and the region/zone in which images are deployed. When deployed, a Server Group is a collection of virtual machines running software. [block:image] { "images": [ { "image": [ "https://files.readme.io/4l9kTko1SVSIcI26iBSR_server_group.png", "server_group.png", "506", "316", "#c92933", "" ] } ] } [/block] * **Security Group**: A *Security Group* defines network traffic access. It is effectively a set of firewall rules defined by an IP range (CIDR) along with a communication protocol (e.g., TCP) and port range. * **Load Balancer**: A *Load Balancer* is associated with an ingress protocol and port range. It balances traffic among instances in its Server Group. Optionally, you can enable health checks for a load balancer, with flexiblity to define health criteria and specify the health check endpoint. * **Cluster**: You can define *Clusters*, which are logical groupings of Server Groups in Spinnaker. ## Deployment Management You use Spinnaker's deployment management features to construct and manage continuous delivery workflows. These are some of the concepts associated with deployment management: * **Pipeline**: *Pipelines* are the key deployment management construct in Spinnaker. They consist of a sequence of actions, known as stages. You can pass parameters from stage to stage along the pipeline. You can start a pipeline manually, or you can configure it to be started by automatic triggers, such as a Jenkins job, a CRON schedule, or a stage in another pipeline. You can configure the pipeline to emit notifications to interested parties at various points during pipeline execution (such as on pipeline start/complete/fail), by email, SMS or HipChat. [block:image] { "images": [ { "image": [ "https://files.readme.io/Y1X8CO7KTkO7vO9x3ZZi_pipeline.png", "pipeline.png", "486", "271", "#4585c5", "" ], "sizing": "smart" } ] } [/block] * **Stage**: A *Stage* in Spinnaker is an action that forms a atomic building block for a pipeline. You can sequence stages in a Pipeline in any order, though some stage sequences may be more common than others. Spinnaker comes pre-packaged with a number of stages, including: * **Bake**: Bakes an image in the specified region. The purpose of baking is to create an immutable image that is typically used for the deploy step. This step is powered by the Rosco service. It’s primarily responsibility is to manage [Packer](https://www.packer.io/intro/) jobs and communicate status back to Orca. This gives the Spinnaker operator the flexibility to create packer templates that are specific to their service team’s needs. For Docker based deployments this is equivalent to the `docker build` command and is usually not needed for deployment **Fields:** *Regions*: Where to bake the image. When using a multi-region bake, Rosco will launch multiple Packer jobs in each region. *Package:* The package that will be passed to your packer template script. Typically a deb or rpm package but can be any package that is an output of your build step. **Note**: your Jenkins job will need to specify your package as an artifact. *Base OS*: The base image or OS that you would like to use for the build step. This can be configured in your `rosco.yml` property file if you need changes. *VM Type (*[*AWS Specific*](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html)*):* HVM or PV. Make sure your instance type is compatible with the type of virtualization selected. The C3 and M3 current generation instance types support PV AMIs. The C1, HI1, HS1, M1, M2, and T1 previous generation instance types support PV AMIs. *Rebake:* By default Spinnaker will not rebake your image if there are no changes to bake. This is typically based on the outputs of your Jenkins build but is cloud provider specific. More details can be found on how Rosco identifies duplicate bake requests [here](https://medium.com/continuous-delivery-scale/spinnaker-rosco-deduping-logic-e03716e04a30#.oelvxdd6s). ***Advanced Options*** These are additional parameters that can be passed down to the packer templates you’ve created. *Template File Name:* The packer template file to use for this bake step. You’ll want want to place this on the disk along with the other default packer templates that are provided for you. Typically here: `/opt/spinnaker/config` *Extended Attributes:* These are additional attributes defined by a user that are passed down to the Packer template. These can be used in your packer JSON template file by using the variable like `{{user 'name_of_ext_attr``'``}}` *Var File Name:* The [packer variable file](https://www.packer.io/docs/templates/user-variables.html) to use. This file must already exist on the file system. *Base AMI or Image:* The image to use when baking if you need a custom image or a dynamic image that is found from an upstream `Find Image From Tags` step or something similar. *AMI Name (AWS Specific):* The prefix of the image name that is used when the image is created and stored with the image registry. The default is `$package-$arch-$ami_suffix-$store_type` *AMI Suffix (AWS Specific):* The suffix that is used after the AMI name. String of date in format YYYYMMDDHHmm, default is calculated from timestamp. *Enhanced Networking (AWS Specific):* This is whether to launch the bake instance with [enhanced networking](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html). This is AWS specific. * **Deploy**: Deploys a previously baked or found image. * **Destroy Server Group**: Destroys a server group. * **Disable Server Group**: Disables a server group. * **Enable Server Group**: Enables a server group. * **Find Image**: Finds a previously-baked image to deploy into an existing cluster. * **Jenkins**: Runs a Jenkins job. * **Manual Judgment**: Waits for user approval before continuing. * **Modify Scaling Process**: Suspend or resume server group scaling processes. * **Pipeline**: Runs a pipeline. This allows you to compose pipelines hierarchically. * **Quick Patch Server Group**: Quickly patches a server group (used for emergency patches). * **Resize Server Group**: Resizes a server group. * **Script**: Runs an arbitrary shell script. * **Shrink Cluster**: Shrinks a cluster. * **Wait**: Waits a specified period of time.