Spinnaker第八节—Deck代码详解

快来打我* 2023-07-07 12:50 0阅读 0赞

# 前言 #

说实话作为一个后端语言的工程师来说，Spinnaker的Deck代码是我研究起来最费劲的，因为Spinnaker的UI设计并没有采用antd之类的前端脚手架，而是纯靠angular+typescript+html一点点写出来的，不仅需要有这些js语言的基础，还要找到项目内代码之间的引用关系，对于js项目来说引用关系确实需要花时间一点点的去review代码。不过经过努力最终还是啃下了，越是困难的事情，越是有收获。

# Review入口 #

Spinnaker所有跟云厂商有关的微服务节点的目录结构都是核心的放在core内，每家云私有的部分放在以自己缩写的目录中，deck也遵循这个规则。以阿里云为例，review入口从alicloud.module.tx中开始。

CloudProviderRegistry.registerProvider('alicloud', {
        name: 'AlibabaCloud',
        logo: {
          path: require('./logo/alicloud.png'),
        },
        image: {
          reader: 'alicloudImageReader',
        },
        serverGroup: {
          transformer: 'alicloudServerGroupTransformer',
          detailsTemplateUrl: require('./serverGroup/details/serverGroupDetails.html'),
          detailsController: 'alicloudServerGroupDetailsCtrl',
          // CloneServerGroupModal: CloneServerGroupAlicloud,
          cloneServerGroupTemplateUrl: require('./serverGroup/configure/wizard/serverGroupWizard.html'),
          cloneServerGroupController: 'alicloudCloneServerGroupCtrl',
          commandBuilder: 'alicloudServerGroupCommandBuilder',
          configurationService: 'alicloudServerGroupConfigurationService',
        },
        instance: {
          instanceTypeService: 'alicloudInstanceTypeService',
          detailsTemplateUrl: require('./instance/details/instanceDetails.html'),
          detailsController: 'alicloudInstanceDetailsCtrl',
        },
        securityGroup: {
          transformer: 'alicloudSecurityGroupTransformer',
          writer: 'alicloudSecurityGroupWriter',
          reader: 'alicloudSecurityGroupReader',
          detailsTemplateUrl: require('./securityGroup/details/securityGroupDetail.html'),
          detailsController: 'alicloudSecurityGroupDetailsCtrl',
          // CreateSecurityGroupModal: CreateSecurityGroup,
          createSecurityGroupTemplateUrl: require('./securityGroup/configure/createSecurityGroup.html'),
          createSecurityGroupController: 'alicloudCreateSecurityGroupCtrl',
        },
        loadBalancer: {
          transformer: 'alicloudLoadBalancerTransformer',
          detailsTemplateUrl: require('./loadBalancer/details/loadBalancerDetail.html'),
          detailsController: 'alicloudLoadBalancerDetailsCtrl',
          // CreateLoadBalancerModal: ConfigureLoadBalancerModal,
          createLoadBalancerTemplateUrl: require('./loadBalancer/configure/createLoadBalancer.html'),
          createLoadBalancerController: 'alicloudCreateLoadBalancerCtrl',
        },
      });

此处注册了阿里云的服务，定义了名称与图标， 图标的展示以及前端UI据大部分的展示已经在core中实现了，而这里定义的都是自定义的部分。

image定义的是镜像相关的内容，因为在deploy和弹性伸缩的创建时需要与云平台交互取到镜像列表的，这部分云厂商接口都不一样，所以要个性处理。为什么没有writer呢？因为Spinnaker的镜像制作是又bake阶段实现的，交给了rosco这个微服务节点，而rosco本质也是将http请求转化为packer命令，所以镜像的制作是由packer来做的，spinnaker代码本身并未涉及。

servergroup是spinnaker的核心对象，是专门处理弹性伸缩的，当然它并不是孤立的，无论哪家云平台，弹性伸缩部分也都需要与镜像、实例类型、安全组、LoadBalance这些关联的，所以servergroup并不能孤立的使用。

transformer代码在serverGroup.transformer.ts，convertServerGroupCommandToDeployConfiguration方法将command转化为configuration，最终会被serverGroupWirter.ts调用。

detailsTemplateUrl和detailsController这是一对大宝贝，前者是右侧详细信息的html模板，后者是该模板的数据来源服务。功能位置：![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3llamluZ3RhbzcwMw_size_16_color_FFFFFF_t_70][]

核心代码在serverGroupDetails.alicloud.controller.ts的retrieveServerGroup()方法，可见数据是从ServerGroupReader中来的：

commandBuilder，js中的代理模式，此处不好理解，需要详细说明，以buildServerGroupCommandFromPipeline为例。  
      modules\\alicloud\\src\\serverGroup\\configure\\serverGroupCommandBuilder.service.ts中定义了buildServerGroupCommandFromPipeline的实现，构造一个command复杂对象。         
      modules\\core\\src\\serverGroup\\configure\\common\\serverGroupCommandBuilder.service.ts中通过代理模式对其进行引用  
      modules\\core\\src\\pipeline\\config\\stages\\deploy\\deployStage.js是真正的调用者

configurationService 实例类型、lb列表框、安全组列表框等配套服务，正如前文所说，弹性伸缩组与这些配套资源需要一起使用。

把ServerGroup的注册部分看完，剩下的也就迎刃而解了instance、securityGroup、loadBalancer，都是类似的规则。

# Pipeline原理 #

Spinnaker中对资源的增删改查分为两种方式，第一种是INFRASTRUCTURE中对弹性伸缩、LoadBalance、安全组这三种资源的直接操作；第二种是将其封装成一个个的固化的stage集成到pipeline流水线中。我们这里看下pipeline的前端代码是怎么实现的。Pipeline的核心是Registry.pipeline.registerStage：注册Stage。

以tagImageStage为例代码在modules\\alicloud\\src\\pipeline\\stages\\tagImage\\alicloudTagImageStage.js

Registry.pipeline.registerStage({
          provides: 'upsertImageTags',
          cloudProvider: 'alicloud',
          templateUrl: require('./tagImageStage.html'),
          executionDetailsUrl: require('./tagImageExecutionDetails.html'),
          executionConfigSections: ['tagImageConfig', 'taskStatus'],
          validators: [
            { type: 'requiredField', fieldName: 'region' },
            { type: 'requiredField', fieldName: 'tags' },
          ],
        });

provides： stage的标识；cloudProvider： 云平台标识；templateUrl： stage的配置页面；executionDetailsUrl：pipeline中stage详情展示；executionConfigSections： pipeline执行信息中的导航；validators： form校验。通过这些关联关系的配置，将前面说讲的对资源的操作封装到了stage中来。

再来看这个环节注册器Registry.ts的代码，分析registerStage的细节，看到就2行代码：

public registerStage(stageConfig: IStageTypeConfig): void {
        this.stageTypes.push(stageConfig);
        this.normalizeStageTypes();
      }

stageTypes是IStageTypeConfig数组（IStageTypeConfig.ts中定义），normalizeStageTypes中有一个对parent的处理，具有parent的如果有些默认值为空，可以从同provides的parent中继承。

现在知道如何存的了，下面看如何查找的。pipelineConfigurer.html是pipeline配置页面，聚焦pipelineConfigurerCtrl.addStage()方法，但这里看到的只是流程图的变更，并没有定位到具体的stage页面，一直找下去，其实在这里stage.module.js

.directive('pipelineConfigStage', function() {
        return {
          restrict: 'E',
          require: '^pipelineConfigurer',
          scope: {
            viewState: '=',
            application: '=',
            pipeline: '=',
            stageFieldUpdated: '<',
          },
          controller: 'StageConfigCtrl as stageConfigCtrl',
          templateUrl: require('./stage.html'),
          link: function(scope, elem, attrs, pipelineConfigurerCtrl) {
            scope.pipelineConfigurerCtrl = pipelineConfigurerCtrl;
          },
        };
      })

跟入controller中，发现取的是options.stageTypes，核心代码：$scope.options.stageTypes = Registry.pipeline.getConfigurableStageTypes(accounts);回到Registry.pipeline中找到相关代码：

public getConfigurableStageTypes(accounts?: IAccountDetails[]): IStageTypeConfig[] {
        const providers: string[] = isNil(accounts) ? [] : Array.from(new Set(accounts.map(a => a.cloudProvider)));
        const allStageTypes = this.getStageTypes();
        let configurableStageTypes = allStageTypes.filter(stageType => !stageType.synthetic && !stageType.provides);
        if (providers.length === 0) {
          return configurableStageTypes;
        }
        configurableStageTypes.forEach(
          type => (type.cloudProviders = this.getCloudProvidersForStage(type, allStageTypes, accounts)),
        );
        configurableStageTypes = configurableStageTypes.filter(type => {
          return !accounts.every(a => {
            const p = CloudProviderRegistry.getProvider(a.cloudProvider, a.skin);
            return isExcludedStageType(type, p);
          });
        });
        return configurableStageTypes
          .filter(stageType => stageType.cloudProviders.length)
          .sort((a, b) => a.label.localeCompare(b.label));
      }

# Reader和Writer原理 #

以镜像读取reader为例modules\\core\\src\\image\\image.reader.ts，看得出使用的是代理模式：

public findImages(params: IFindImageParams): IPromise<IImage[]> {
        return this.getDelegate(params.provider).findImages(params);
      }
      
      private getDelegate(cloudProvider: string): IImageReader {
        return this.providerServiceDelegate.getDelegate<IImageReader>(cloudProvider, 'image.reader');
      }

服务的注册和获取在core/cloudProvider/providerService.delegate中：

public getDelegate<T>(provider: string, serviceKey: string, skin?: string): T {
        const service = CloudProviderRegistry.getValue(provider, serviceKey, skin);
        if (isString(service) && this.$injector.has(service)) {
          // service is a string, it's an AngularJS service
          return this.$injector.get<T>(service, 'providerDelegate');
        } else if (isFunction(service)) {
          // service is a Function, assume it's service class, so new() it
          return new service();
        } else {
          throw new Error('No "' + serviceKey + '" service found for provider "' + provider + '"');
        }
      }

可见providerService这一层也只是逻辑层，真正存储维护都交给了CloudProviderRegistry，其中有getValue方法，也必有setValue方法，而setValue方法的调用的内容就在刚开始介绍的alicloud.module.tx中。所以core中image.reader通过alicloud.module.tx的代理注册，最终调用的是阿里云自己项目中的image.reader。

了解了reader，writer以及其他service本质上都一样了，都是core中通过代理调用了云厂商私有的实现。

# 总结 #

1 $\{clouddriver\}.module.tx是最重要的入口，里面的内容必须要掌握。  
  2 pipeline中代码是对资源stage化的封装，真正与后端的交互逻辑还是在资源本身的目录中寻找。  
  3 core中通过代理模式获取到云平台私有实现。  
  4 留意下modules\\core\\src\\forms下的自定义组件，自己做功能扩展时优先用现成的，保持统一风格。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3llamluZ3RhbzcwMw_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200223204353899.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3llamluZ3RhbzcwMw==,size_16,color_FFFFFF,t_70