Spinnaker
https://gyazo.com/9b0351d837d8da4a11c38b55461fbaf7
Cloud Native Continuous Delivery
Fast, safe, repeatable deployments for every Enterprise
Spinnaker is an open source, multi-cloud continuous delivery platform for releasing software changes with high velocity and confidence.
Created at Netflix, it has been battle-tested in production by hundreds of teams over millions of deployments. It combines a powerful and flexible pipeline management system with integrations to the major cloud providers.
Multi-Cloud
Deploy across multiple cloud providers including AWS EC2, Kubernetes, Google Compute Engine, Google Kubernetes Engine, Google App Engine, Microsoft Azure, Openstack, Cloud Foundry, and Oracle Cloud Infrastructure, with DC/OS coming soon. Automated Releases
Create deployment pipelines that run integration and system tests, spin up and down server groups, and monitor your rollouts. Trigger pipelines via git events, Jenkins, Travis CI, Docker, CRON, or other Spinnaker pipelines. Built-in Deployment Best Practices
Create and deploy immutable images for faster rollouts, easier rollbacks, and the elimination of hard to debug configuration drift issues. Leverage an immutable infrastructure in the cloud with built-in deployment strategies such as red/black and canary deployments.
Active Community
Join a community that includes Netflix, Google, Microsoft, Veritas, Target, Kenzan, Schibsted, and many others, actively working to maintain and improve Spinnaker.
公式本
軽い解說
Who uses Spinaker?
類似品
Application$ \niCluster$ \niServer group
https://gyazo.com/e3ed7a3a58251b5f5e3e0d55adcb2ed0
Load balancer、Firewall の槪念も有る
https://gyazo.com/067dc5a1b94317ea8bfe1db171e8d414
Deck is the browser-based UI.
Gate is the API gateway. The Spinnaker UI and all api callers communicate with Spinnaker via Gate.
Orca is the orchestration engine. It handles all ad-hoc operations and pipelines. Read more on the Orca Service Overview.
Clouddriver is responsible for all mutating calls to the cloud providers and for indexing/caching all deployed resources.
Front50 is used to persist the metadata of applications, pipelines, projects and notifications.
Rosco is the bakery. It produces immutable VM images (or image templates) for various cloud providers. It is used to produce machine images (for example GCE images, AWS AMIs, Azure VM images). It currently wraps packer, but will be expanded to support additional mechanisms for producing images.
Igor is used to trigger pipelines via continuous integration jobs in systems like Jenkins and Travis CI, and it allows Jenkins/Travis stages to be used in pipelines.
Echo is Spinnaker’s eventing bus. It supports sending notifications (e.g. Slack, email, SMS), and acts on incoming webhooks from services like Github.
Fiat is Spinnaker’s authorization service. It is used to query a user’s access permissions for accounts, applications and service accounts.
Kayenta provides automated canary analysis for Spinnaker.
Halyard is Spinnaker’s configuration service. Halyard manages the lifecycle of each of the above services. It only interacts with these services during Spinnaker startup, updates, and rollbacks.
認證・認可
Google Groups (through a Google Apps for Work organization)
GitHub Teams
LDAP
File based role provider
Argo CDArgo.iconやFlux CDとは違って、強制GitOpsではない 勿論實裝は出來る
複數のapplicationを、Multi cloud/multi region/multi AZにcanary deployする事が出來る
pipelineの例https://gyazo.com/9eb2d86d678a7b523f2857852798aa91
Auto scalingの機能も持ってゐる (多分EC2とかで使ふのだらう…)
Provider
packer使ってるから單なるEC2も出來る筈だが?
使へるparts達
General
AWS CodeBuild
Bake
Canary Analysis
Check Preconditions
Clone Server Group
Deploy
Destroy Server Group
Disable Cluster
Disable Server Group
Enable Server Group
Find Artifact From Execution
Find Image From Cluster
Find Image From Tags
Google Cloud Build
Jenkins
Manual Judgment
Pipeline
Resize Server Group
Rollback Cluster
Run Job
Scale Down Cluster
Script
Shrink Cluster
Tag Image
Wait
Webhook
Wercker
App Engine
Start a Server Group
Stop a Server Group
Edit Load Balancer
AWS
Modify AWS Scaling Process
Kubernetes
Bake (Manifest)
Delete (Manifest)
Deploy (Manifest)
Find Artifacts From Resource
Patch (Manifest)
Scale (Manifest)
Undo Rollout (Manifest)
Custom Stages
Custom Webhook
Custom Job
導入するなら
deployとreleaseを分ける
先ずdeployし、それから確認・E2E test・QA・承認を行ふ。その後releaseする
無論例外は例外として扱ふものとして
「このKubernetesのdeployだけ管理したい」だったらArgo CDやFlux CDのはうが好い。Canary releaseも出來る 「このECSだけ」ならCode Deployとか
DockerDocker.icon for Desktopで試す contextをdocker-desktopに切り替へる
s/kubectl/kubectl.exe/
$ bash install.sh 0.14.1
code:stdout
customresourcedefinition.apiextensions.k8s.io/clusterserviceversions.operators.coreos.com created
customresourcedefinition.apiextensions.k8s.io/installplans.operators.coreos.com created
customresourcedefinition.apiextensions.k8s.io/subscriptions.operators.coreos.com created
customresourcedefinition.apiextensions.k8s.io/catalogsources.operators.coreos.com created
customresourcedefinition.apiextensions.k8s.io/operatorgroups.operators.coreos.com created
namespace/olm created
namespace/operators created
serviceaccount/olm-operator-serviceaccount created
clusterrole.rbac.authorization.k8s.io/system:controller:operator-lifecycle-manager created
clusterrolebinding.rbac.authorization.k8s.io/olm-operator-binding-olm created
deployment.apps/olm-operator created
deployment.apps/catalog-operator created
clusterrole.rbac.authorization.k8s.io/aggregate-olm-edit created
clusterrole.rbac.authorization.k8s.io/aggregate-olm-view created
operatorgroup.operators.coreos.com/global-operators created
operatorgroup.operators.coreos.com/olm-operators created
clusterserviceversion.operators.coreos.com/packageserver created
catalogsource.operators.coreos.com/operatorhubio-catalog created
Waiting for deployment "olm-operator" rollout to finish: 0 of 1 updated replicas are available...
deployment "olm-operator" successfully rolled out
deployment "catalog-operator" successfully rolled out
Package server phase: Installing
Package server phase: Succeeded
deployment "packageserver" successfully rolled out
code:stdout
subscription.operators.coreos.com/my-spinnaker-operator created
先が長いので止めた