后端DevOps云原生微服务【免费下载链接】spinnakerSpinnaker is an open source, multi-cloud continuous delivery platform for releasing software changes with high velocity and confidence.项目地址https://gitcode.com/gh_mirrors/sp/spinnaker点击查看免费下载本文围绕 Spinnaker 开源仓库rosco/halconfig目录展开系统讲解 Rosco镜像烘焙服务骨架配置文件的定位、Halyard 部署时配置拼接的工作原理、该目录当前的弃用状态以及在现代 Rosco 版本中设置默认配置值的正确姿势——涵盖 halconfig 目录、halconfig/rosco.yml、halconfig/images.yml 与 packer 模板目录 的全部内容并对照 rosco-core 源码 给出实现级证据。读完本文你将掌握 Rosco 烘焙配置的来龙去脉能够正确判断哪些配置该写进 halconfig、哪些该迁移到rosco-web/config/rosco.yml或代码默认值并理解 packer 模板与bakeryDefaults的配合关系。一、halconfig 目录是什么Rosco 的“骨架配置”rosco/halconfig/README.md开门见山地说明了该目录的定位This directory contains a skeleton rosco config to which Halyard concatenates its generated deployment-specific config.即rosco/halconfig存放的是 Rosco 的骨架skeleton配置HalyardSpinnaker 部署管理工具在生成部署专属配置时会把两部分内容**拼接concatenate**到一起骨架配置提供通用默认值Halyard 生成的配置提供当前部署环境的具体值。这与 Spinnaker 其他微服务的 halconfig 目录设计一脉相承。当前目录内共包含三类文件文件作用README.md目录用途与弃用说明rosco.yml骨架主配置redis、server、以及各云厂商的bakeryDefaultsimages.yml更早期的骨架镜像配置同样已弃用packer/Rosco 使用的 Packer 构建模板与安装脚本骨架配置中的环境变量占位符halconfig/rosco.yml 的最典型特征是大量使用${...}占位符其中一部分引用 Halyard 生成的服务配置另一部分引用环境变量redis: connection: ${services.redis.baseUrl:redis://localhost:6379} server: port: ${services.rosco.port:8087} address: ${services.rosco.host:localhost}${services.redis.baseUrl:redis://localhost:6379}优先取 Halyard 生成的services.redis.baseUrl取不到时回退到redis://localhost:6379${services.rosco.port:8087}取 Halyard 的services.rosco.port默认回退8087即 Rosco 的默认 HTTP 端口${services.rosco.host:localhost}绑定地址默认localhost。这一设计正是“骨架 Halyard 拼接”的直观体现骨架文件用带默认值的占位符描述通用行为具体部署值由 Halyard 注入。二、重要现状halconfig 配置已被弃用README 同时给出了明确的弃用声明这是理解该目录时最重要的一点These configs aredeprecatedand in general should not be further updated. To set a default config value, either set the value inrosco-web/config/rosco.ymlor set a default in the code reading the config property.即rosco/halconfig下的配置已弃用原则上不应继续更新。需要设置默认配置值时官方推荐两条迁移路径在 rosco-web/config/rosco.yml 中设置默认值——这是当前 Rosco 运行时真正加载的配置文件在读取该配置属性的代码中设置默认值——即 Spring 的${property:defaultValue}语法或代码内直接兜底。为什么会有这种迁移从部署视角看Rosco 的镜像内实际使用的配置位于/opt/rosco/config/而 halconfig 中的内容只服务于 Halyard 拼接流程。随着 Spinnaker 部署模型向统一配置unified config演进halconfig 骨架的维护成本与歧义例如多份 yml 的默认值到底以谁为准超过了它的价值因此社区选择收敛配置入口。halconfig/images.yml同样处于弃用状态它列出的 AWS/Azure/Docker/GCE 基础镜像定义在 halconfig/rosco.yml 中已有更完整的对应版本。三、当前权威配置入口rosco-web/config/rosco.yml按 README 的指引rosco-web/config/rosco.yml 才是现版本应维护默认值的位置。它涵盖了骨架配置的全部核心项并补充了 halconfig 中没有的细节逐项说明如下。3.1 服务端口与烘焙目录server: port: 8087 rosco: configDir: /opt/rosco/config/packer jobs: local: timeoutMinutes: 30server.portRosco HTTP 端口默认8087Dockerfile 的健康检查也探测该端口rosco.configDirPacker 模板与脚本所在目录。镜像内固定为/opt/rosco/config/packer由 Dockerfile.ubuntu 第 78 行COPY halconfig/packer /opt/rosco/config/packer把本仓库的 packer 目录拷入镜像configDir最终会以{{user \configDir}} 形式注入每个 Packer 模板rosco.jobs.local.timeoutMinutes本地 Job 执行的超时时间默认 30 分钟防止烘焙任务悬挂。在源码侧CloudProviderBakeHandler.groovy 通过Value(${rosco.config-dir})读取该路径并在produceBakeRecipe中拼接出模板文件的完整路径$configDir/$finalTemplateFileName再交给PackerCommandFactory生成最终的packer build命令。3.2 Packer 行为参数packer: # Set this if running Packer 1.4.0 for timestamp prepended output timestamp: false # Add additional parameters that will always be passed to packer build here # additionalParameters: # - on-errorabort # - -var bakedByRoscopacker.timestampPacker 1.4.0 起构建日志会自带时间戳前缀Rosco 解析日志时按此开关适配packer.additionalParameters需要无条件附加到每次packer build的参数列表例如on-errorabort失败即中止或自定义-var。3.3 软件源仓库debian / yum / chocolatey# debianRepository: http://dl.bintray.com/spinnaker/ospackages trusty main;http://other.repo.com/repo/packages trusty main # yumRepository: https://jfrog.bintray.com/yum/repos/some-package # chocolateyRepository: https://chocolatey.org/api/v2/debianRepository烘焙 Debian 系镜像时追加到/etc/apt/sources.list.d/spinnaker.list的 apt 源多个源用分号分隔yumRepository烘焙 RPM 系镜像时写入/etc/yum.repos.d/的 yum 源chocolateyRepository烘焙 NuGet 系Windows镜像时的 chocolatey 源均支持空格分隔的多源列表并且可以在某个baseImage上通过customRepository覆盖全局配置。源码印证见 CloudProviderBakeHandler.groovy三个仓库分别由Value(${debian-repository:})、Value(${yum-repository:})、Value(${chocolatey-repository:})注入在produceBakeRecipe中按packageTypeDEB/RPM/NUPKG选择对应仓库写入parameterMap.repository最终传给模板中的install_packages.sh。3.4 默认云厂商与需要 root 的模板defaultCloudProviderType: aws templatesNeedingRoot: aws-chroot.jsondefaultCloudProviderType未显式指定云厂商时的默认值本仓库中为awstemplatesNeedingRoot列出需要以 root 身份执行/usr/bin/packer的模板本仓库为aws-chroot.jsonchroot 构建必须挂载块设备。Rosco 默认以spinnaker用户运行、无 sudo 权限因此使用这些模板前需在/etc/sudoers.d/spinnaker中添加spinnaker ALL(ALL) NOPASSWD: /usr/bin/packerREADME 与配置注释均特别提示为 spinnaker 授予 packer 的免密 sudo 存在被恶意利用控制机器的风险需谨慎评估。源码侧CloudProviderBakeHandler.groovy 将templates-needing-root读取为列表并在getBaseCommand中判断若模板文件名命中列表则在 packer 命令前加sudo前缀否则为空串。四、bakeryDefaults各云厂商的基础镜像骨架halconfig/rosco.yml 的主体是按云厂商划分的bakeryDefaults配置在rosco-web/config/rosco.yml中缺失的部分在此补全其通用结构为provider: enabled: ${PROVIDER_ENABLED:false} bakeryDefaults: templateFile: 模板文件名 baseImages: - baseImage: id: 镜像 ID即 base_os shortDescription: ... detailedDescription: ... packageType: deb | rpm | nupkg virtualizationSettings: - region: ... instanceType: ... sourceImage / sourceAmi / sourceImageId: ... sshUserName: ...4.1 统一的启用开关与条件装配每个厂商都以enabled: ${XXX_ENABLED:false}开头如${AWS_ENABLED:false}、${GOOGLE_ENABLED:false}、${DOCKER_ENABLED:false}。这个开关在源码中对应 Spring 的ConditionalOnPropertyRoscoAWSConfiguration.groovy 标注ConditionalOnProperty(aws.enabled)AWSBakeryDefaultsBean.java 同样以ConditionalOnProperty(aws.enabled)控制awsBakeryDefaultsBean并通过ConfigurationProperties(aws.bakery-defaults)将 yml 中的aws.bakeryDefaults段映射为配置对象。也就是说只有对应enabled: true的厂商才会装配BakeHandler与默认值 Bean并在PostConstruct阶段注册进 DefaultCloudProviderBakeHandlerRegistry。注意配置注释特别提醒XXX_ENABLED这类环境变量并不在 spinnaker/spinnaker 项目的 unified config 中定义。若要把本段配置拷贝到预构建镜像的rosco-local.yml必须把AWS_ENABLED换成SPINNAKER_AWS_ENABLED其他厂商同理或显式设enabled: true。4.2 AWS最完整的骨架示例AWS 段的bakeryDefaults覆盖了模板选择、虚拟化类型与竞拍价aws: enabled: ${AWS_ENABLED:false} bakeryDefaults: awsAssociatePublicIpAddress: true templateFile: aws-ebs.json defaultVirtualizationType: hvm baseImages: - baseImage: id: ubuntu shortDescription: v12.04 detailedDescription: Ubuntu Precise Pangolin v12.04 packageType: deb templateFile: aws-ebs.json virtualizationSettings: - region: us-east-1 virtualizationType: hvm instanceType: t2.micro sourceAmi: ami-d4aed0bc sshUserName: ubuntu spotPrice: 0 spotPriceAutoProduct: Linux/UNIX (Amazon VPC)关键参数含义awsAssociatePublicIpAddress构建实例是否分配公网 IP默认truetemplateFile默认 Packer 模板AWS 默认aws-ebs.json注释指出需要share_with/copy_to能力时应换成aws-multi-ebs.json此时还需设置环境变量SPINNAKER_AWS_DEFAULT_ACCOUNT要共享 AMI 的账号 ID与SPINNAKER_AWS_DEFAULT_REGIONdefaultVirtualizationType默认虚拟化类型hvm对应源码 AWSBakeryDefaultsBean.java 中${aws.bakery-defaults.default-virtualization-type:hvm}的读取与兜底spotPrice竞拍价上限auto表示自动探测最优竞拍价0表示按需实例默认spotPriceAutoProduct使用spotPrice: auto时的必填项取值限定为Linux/UNIX、Linux/UNIX (Amazon VPC)、SUSE Linux、Windows、Windows (Amazon VPC)等每个virtualizationSettings由region virtualizationType instanceType sourceAmi sshUserName唯一确定一种可烘焙镜像组合同一baseImage下可并列多个 region 与虚拟化类型如 hvm 用t2.micro、pv 用m3.medium。配置注释还说明baseImage级可覆盖默认模板templateFile与全局软件源customRepository例如customRepository: http://dl.bintray.com/spinnaker/ospackages bionic main。4.3 GoogleGCE镜像族与镜像二选一google: enabled: ${GOOGLE_ENABLED:false} bakeryDefaults: zone: us-central1-f network: default useInternalIp: false templateFile: gce.json baseImages: - baseImage: id: xenial shortDescription: v16.04 detailedDescription: Ubuntu Xenial Xerus v16.04 packageType: deb isImageFamily: true virtualizationSettings: sourceImageFamily: ubuntu-1604-ltssourceImage与sourceImageFamily二选一同时设置时sourceImage优先isImageFamily: true时 Deck 会在 UI 提示该选项代表镜像族而非具体镜像zone、network、useInternalIp为 GCE 构建实例的默认参数。4.4 Azurepublisher / offer / sku 三元组azure: enabled: ${AZURE_ENABLED:false} bakeryDefaults: templateFile: azure-linux.pkr.hcl baseImages: - baseImage: id: ubuntu-1604 shortDescription: v16.04 detailedDescription: Ubuntu Server 16.04-LTS publisher: Canonical offer: UbuntuServer sku: 16.04-LTS version: 16.04.201612140 osType: Linux packageType: debAzure 的源镜像通过 Marketplace 的publisher/offer/sku/version描述Windows 基础镜像额外指定templateFile: azure-windows.pkr.hcl与packageType: nupkg。同时注意仓库中已同时提供 azure-linux.pkr.hcl 与更新的托管镜像版本 azure-linux-managed-image.pkr.hcl。4.5 Docker最简烘焙模型docker: enabled: ${DOCKER_ENABLED:false} bakeryDefaults: targetRepository: ${DOCKER_TARGET_REPOSITORY:} templateFile: docker.json baseImages: - baseImage: id: precise shortDescription: v12.04 detailedDescription: Ubuntu Precise Pangolin v12.04 packageType: deb virtualizationSettings: sourceImage: ubuntu:preciseDocker 烘焙以sourceImage基础镜像 tag为输入、targetRepository目标仓库为输出不涉及 region 与实例类型。4.6 阿里云 / 华为云 / 腾讯云阿里云alicloud以region instanceType sourceImage sshUserName定义如cn-hangzhou区域ecs.c5.large实例、ubuntu_16_04_64_20G_alibase_20190620.vhd源镜像模板 alicloud.json华为云huaweicloudbakeryDefaults中直接包含一组认证与网络参数占位符authUrl、username、password、projectName、domainName、insecure、vpcId、subnetId、eipBandwidthSize默认 2、securityGroup源镜像以不可变的 UUIDsourceImageId标识可在控制台或镜像 API 查询腾讯云tencentcloudsecretId、secretKey认证virtualizationSettings含region/zone/instanceType/sourceImageId/sshUsername覆盖 Ubuntu 16.04、Debian 9.0、CentOS 7.6 三类基础镜像。4.7 一份独立的镜像清单images.ymlhalconfig/images.yml 是更早形态的骨架镜像定义结构与bakeryDefaults.baseImages一致AWS 的 ubuntu/trusty/windows-2012-r2、Azure 的五个 Marketplace 镜像、Docker 的 precise/trusty、GCE 的 xenial/bionic 镜像族。它与 halconfig/rosco.yml 存在部分重复同样随目录整体弃用阅读时应以rosco.yml中的bakeryDefaults为准。五、Packer 模板骨架烘焙命令的落地形态rosco/halconfig/packer存放的是直接喂给 Packer 的构建模板与脚本。它们遵循变量占位符 统一安装脚本模式所有运行时值通过{{user \xxx}} 注入软件安装统一走 install_packages.sh。5.1 统一的变量契约以 aws-ebs.json 为例其variables定义了各云厂商模板共通的契约字段变量含义appversion/build_host/build_info_url写入镜像标签/描述的构建元数据repository本次烘焙使用的软件源由 3.3 节的仓库配置决定package_typedeb/rpm/nupkgpackages要安装的包名空格分隔upgrade是否先执行系统升级unattended-upgrade/yum updateconfigDir模板与脚本所在目录用于定位install_packages.shaws-ebs.json使用amazon-ebsbuilder把source_ami烘焙为ami_name并把appversion、build_host、build_info_url写入 AMI 标签、packages写入运行标签aws-subnet_id/aws_vpc_id默认从环境变量AWS_SUBNET_ID/AWS_VPC_ID读取。5.2 各模板的差异定位aws-chroot.jsonamazon-chrootbuilder直接在块设备上烘焙、不启动实例因此需要 root 权限对应templatesNeedingRoot并通过disable_servicestrue环境变量让install_packages.sh临时创建/usr/sbin/policy-rc.d阻止服务自动启动规避 chroot 环境中的服务启动坑aws-multi-ebs.json在aws-ebs.json基础上增加ami_usersshare_with_1..10默认全部为SPINNAKER_AWS_DEFAULT_ACCOUNT与ami_regionscopy_to_1..5默认全部为SPINNAKER_AWS_DEFAULT_REGION实现 AMI 跨账号共享与跨区域复制aws-multi-chroot.json 为对应 chroot 版本aws-windows-2012-r2.jsonWindows 基础镜像配合 packer/scripts 下的 PowerShell 脚本如windows-install-packages.ps1、windows-configure-chocolatey.ps1完成 NuGet 包安装gce.jsongooglecomputebuilder支持artifactFile文件 provisioner把 artifacts 传入/tmp/artifacts.json与manifestpost-processor 输出manifestFile供 PackerManifestService 解析烘焙产物 IDdocker.jsondockerbuilder docker-tag/docker-pushpost-processor把基础镜像安装包后提交为新镜像并推送至docker_target_repositoryazure-linux.pkr.hcl采用 Packer HCL2 语法source azure-armbuild块变量以sensitive true声明azure_client_id/azure_client_secret防止日志泄露并在构建末尾执行waagent -force -deprovisionuser完成 Azure 镜像通用化。5.3 install_packages.sh烘焙过程中的安装引擎install_packages.sh 是所有模板共用的软件安装脚本核心逻辑set -e保证构建失败即中止先打印脱敏后的repository用sed s/^.*//g剥离凭据部分避免仓库 URL 中的凭据泄漏get_artifact_references把仓库列表写入/tmp/repos若存在/tmp/artifacts.jsonGCE 等通过 file provisioner 传入的工件清单用jq解析每个 artifact 的reference——最后一段是包名、其余段是安装源provision_deb向/etc/apt/sources.list.d/spinnaker.list追加 deb 源upgradetrue时执行unattended-upgrade -v然后按顺序apt-get install各包结束后清理源文件provision_rpm为每个源生成/tmp/spinnaker-ts-i.repo并移入/etc/yum.repos.d/upgradetrue时yum update再逐个yum installdisable_servicestrue时chroot 模板创建/移除policy-rc.d以控制服务启动。六、从源码看配置如何被消费一次烘焙的完整链路把配置文件与源码串起来一次烘焙请求的消费链路如下对应 CloudProviderBakeHandler.groovy 的produceBakeRecipe读取烘焙默认值getBakeryDefaults()返回由ConfigurationProperties(aws.bakery-defaults)等映射的bakeryDefaults对象仅在xxx.enabledtrue时装配见 RoscoConfiguration.groovy 与各厂商 Configuration匹配基础镜像findBaseImage按bakeRequest.base_os在baseImages中查找id匹配项找不到则抛IllegalArgumentException定位虚拟化设置findVirtualizationSettings(region, bakeRequest)根据 region 与请求参数选择对应的virtualizationSettings组装参数buildParameterMap把 region、实例类型、源镜像等填入模板变量repository按 packageType 从全局仓库或customRepository决定拼接命令getBaseCommand按templatesNeedingRoot决定是否加sudoPackerCommandFactory.buildPackerCommand生成完整packer build命令configDir作为变量一并传入注册与执行厂商配置在PostConstruct中把BakeHandler注册进 DefaultCloudProviderBakeHandlerRegistry由 Rosco API 分派执行。此外RoscoConfiguration中的 BakeStore 基于 Jedis 使用 Redis 记录烘焙状态这也解释了骨架配置中redis.connection为什么是必须项——Rosco 不依赖 Halyard 默认的 Redis 部署而是直接连接redis://localhost:6379可经${services.redis.baseUrl}覆盖。七、实战建议面对 halconfig 该怎么做基于 README 的弃用声明与仓库现状落地时建议遵循以下原则不再修改 halconfigrosco/halconfig下的rosco.yml、images.yml保留只读作为理解烘焙默认值历史形态与迁移的参考默认值写到 rosco-web/config/rosco.yml新增厂商默认值、模板默认值、仓库配置等一律落到 rosco-web/config/rosco.yml环境变量启用厂商在部署环境设置SPINNAKER_AWS_ENABLEDtrue等对应enabled: ${AWS_ENABLED:false}的占位符而非直接改 halconfig模板与脚本随镜像分发packer/目录经 Dockerfile.ubuntu 拷贝到/opt/rosco/config/packer若要自定义模板应在构建镜像时替换该目录内容并保持变量契约configDir、repository、package_type、packages、upgrade不变root 权限按需最小化仅当确实使用aws-chroot.json等需要 root 的模板时才按 3.4 节配置 sudoers 规则并充分评估安全风险。结语rosco/halconfig是 Spinnaker Rosco 服务配置体系从Halyard 拼接骨架向统一配置文件 代码默认值演进的历史见证。理解它的定位与弃用逻辑能帮助你在实际部署中快速判断默认值应写进 rosco-web/config/rosco.yml厂商开关应通过环境变量控制而bakeryDefaults与 packer 模板的配合关系baseImage匹配 →virtualizationSettings定位 →parameterMap组装 →install_packages.sh安装则构成了 Rosco 镜像烘焙能力的完整闭环。赞分享后端DevOps云原生微服务【免费下载链接】spinnakerSpinnaker is an open source, multi-cloud continuous delivery platform for releasing software changes with high velocity and confidence.项目地址https://gitcode.com/gh_mirrors/sp/spinnaker点击查看免费下载相关推荐Spinnaker Echo halconfig 配置骨架解析Halyard 拼接机制、弃用策略与默认值设置规范Spinnaker Echo halconfig 配置骨架解析Halyard 拼接机制、弃用策略与默认值设置规范 Echo 是 Spinnaker 多集群持续后端DevOps云原生微服务Spinnaker Orca 的 Halyard 骨架配置halconfig解析与弃用迁移指南Spinnaker Orca 的 Halyard 骨架配置halconfig解析与弃用迁移指南 导读 orca/halconfig/ 目录保存的是 Orca后端DevOps云原生微服务Pot 划词翻译完整指南跨平台 OCR 与翻译开箱即用Pot 划词翻译完整指南跨平台 OCR 与翻译开箱即用 Pot 是一款开源免费的跨平台划词翻译与 OCR 工具Windows、macOS、Linux 通用。后端DevOps云原生微服务上一篇dosemu2完全指南如何在Linux系统中无缝运行经典DOS程序下一篇Gammazero/DequeGo语言高性能环形缓冲区双端队列完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考