Spinnaker 是一个持续交付平台，它定位于将产品快速且持续的部署到多种云平台上。
Spinnaker 主要特性：配置一次，随时运行；随地部署，集中化管理；开源。
Spinnaker 组件：
Spinnaker 最初是以实现内部的端到端持续交付为目标，作为 Asgard 的替代，该项目期望重建一个持续交付平台，能够实现：
通过灵活和可配置的管道实现可重复的自动部署
提供一个所有环境的全局视图，一个应用程序可以看见自己的在所属管道中的状态
通过一致且可靠的API，提供可编程配置
易于配置、维护和扩展
兼容Asgard特性
同时，Spinnaker作为云平台部署工具，Spinnaker团队和Google、微软、Pivotal等公司合作，致力于提供在多种平台上实现开箱即用的集群管理和部署功能。目前，Spinnaker可以部署管理AWS和Google云平台（GCP），针对Azure等平台的支持也在进行中。
Spinnaker主要包含2块内容，集群管理和部署管理。
集群管理功能，主要用于管理云上的资源。集群管理将云上资源做了逻辑划分：
机器组：机器组是Spinnaker管理资源的单位。机器组标识了机器实例，并且关联了一个负载均衡器和安全组。每个机器组都拥有独立的配置信息（如机器帐号等）；
安全组：安全组定义了网络访问权限，也就是一般意义上的一组防火墙规则；
负载均衡器：负载均衡器用于将网络流量重定向到机器组中的机器实例，负载均衡器还可以指定一系列规则，用于对机器组中的机器实例做健康检查；
集群：集群是由用户定义的，对机器组的逻辑分组；
部署管理功能用于创建一个持续交付流程。部署管理的核心是管道，在Spinnaker的定义中，管道由一系列的阶段（stages）组成。管道可以由Jenkins、定时器、其他管道或者人工触发。同时，管道可以配置参数和通知，可以在管道一些节点上发出消息。Spinnaker已经内置了一些阶段，如执行自定义脚本、触发Jenkins任务等。
介绍来自 InfoQ
-
Spinnaker采用了微服务体系，而对于整套微服务体系的搭建官方是推荐采用halyard来搭建的。 Halyard对于spinnaker的黑盒使用者比较友好，把对spinnaker的安装、部署、配置、管理等都封装成命令（其实命令也是够复杂的），但对于具有研发基础或者说对于spinnaker比较了解的人来说这种方式有点本末倒置了，本篇在原理上介绍下如何绕过halyard自己搭建spinnaker的
-
一、Spinnaker介绍 持续交付平台（快速且持续的部署到多种云平台上） 特征：配置一次、随时运行；随地部署，集中化管理；快源 实现目标： 1）通过灵活和可配置的管道实现可重复的自动部署 2）提供一个所有环境的全局试图，一个应用程序可以看见自己在所属管道中的状态 3）通过一致且可靠的API，提供可编程配置 4）易于配置、维护和扩展 二、主要功能 集群管理： 1）机器组：Spinnaker管理资
-
这是个真实的事故： 2021/02/22 节后第一个星期一中午的准午餐时间，节后综合症导致的吊儿郎当的神经还未绷紧，突然办公室内全面报警，很多服务都出现或多或少的异常，大家不约而同地说“我去，我的服务里阿里云的机器没有了”！！。 我的直觉告诉我这种批量操作不可能是误删，应该是程序或脚本引起的，赶紧联系阿里云审计日志中查下操作账号和源IP。结果是spinnaker账号在公司内网发起的请求。 因为sp
-
摘要： 这项工作介绍了sPyNNaker 4.0.0，这是用于在SpiNNaker神经形态平台上模拟PyNN定义的尖刺神经网络（SNN）的软件包的最新版本。 提出了支持实时SNN执行的操作，包括一个基于事件的操作系统，该系统有助于高效的时间驱动神经元状态更新和pipelined event-driven spike processing。 讨论了预处理，实时执行和神经元/突触模型的实现，所有这些都
-
1 修改k8s的config认证多个集群 apiVersion: v1 clusters: - cluster: certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR2akNDQXFhZ0F3SUJBZ0lVUzFNSE1PYml4RG1GM3R2ZlgxYTFhR28wdE1vd0RRWUpLb1p
-
交付管道的建立和自动化是持续交付的基础 持续集成 更关注代码质量。持续集成是为了确保随着需求变化而变化的代码，在实现功能的同时，质量不受影响。因此，在每一次构建后会运行单元测试，保证代码级的质量。单元测试会针对每一个特定的输入去判断和观察输出的结果，而单元测试的粒度则用来平衡持续集成的质量和速度。 持续集成的核心价值在于1： 持续集成中的任何一个环节都是自动完成的，无需太多的人工干预，有利于减少重
-
它们还提供了一个警告：如果您能够持续部署到测试系统，有时也会使用术语“持续部署”。 这一切让我很困惑。任何更详细的解释（或附带一个例子）都是赞赏的！
-
介绍 持续交付是频繁对软件应用程序持续更新的概念. 这个想法使在大量频繁的更新面前, 你不必等待在一个指定的特殊时间点, 并且使你的组织在响应过程中变得更好. 一些 Ansible 用户每小时都在部署更新给他们的最终用户甚至更加频繁 – 每时每刻都有代码修改的批准. 要实现这一点, 你需要工具能在零停机的时间内快速的应用这些更新. 本文档详细介绍了如何现实这一目标, 使用 Ansible play
-
我为老东家的 CTO 部门工作的七年里，除了吃饭睡觉码代码，干的最多的事情就是布道。给工程师讲技术，给管理层讲业态，给客户讲故事。但让我很沮丧的是，在离职那天给我留言最多的一条，居然是「很遗憾，再也听不到你讲美食了」。好吧，虽然我们怀揣着改变世界的梦想踏上征程，却总是在路口的料理摊停下了脚步。这个插曲，就算是我这系列文章的引子。 每一个吃货的心里，都住着一个厨子。 每一个码农的心里，都憋着一个梦想
-
目标 无明确目标 知识点 学习使用 travis-ci 对项目进行持续集成测试 (https://travis-ci.org/ ) 课程内容 首先来看看这个项目：https://github.com/Ricardo-Li/node-practice-3 （图1） 类似这样的 badges，在很多项目中都可以看到。前者是告诉我们，这个项目的测试目前是通过的；后者是告诉我们，这个测试的行覆盖率是多少。
-
1 概念 Jenkins可选配置参数相当多。基本可以归为这么几类： 构建触发配置：例如配置gitlab提交代码触发构建，或者每天、每周定时触发构建 构建工具配置：例如配置jdk/maven/gradle等 构建后配置：例如配置发送邮件、自动开jira bug等 Jenkins的外挂工具，都是通过插件机制来解决的，常见插件如下： iOS专用：Xcode integration Android专用：G