竹笋

首页 » 问答 » 常识 » GitLab1311增加K8S代理和管
TUhjnbcbe - 2022/12/9 22:42:00

4月22日是世界地球日,善待地球,保护我们的环境!今天Gitlab也发布月度版本13.11。新增加的功能有GitLabKubernetes代理,可是实现基于拉的一键进群部署。兼容管道配置,可以定义可强制执行的管道,管道中可以配置好相应遵从框架的任何项目(甚至是自定义框架)运行。更多功能,请和虫虫一起学习。

概述

控制可以使自动化随着团队成长和扩展而步入正轨,也能减轻合规性工作任务。GitLab新推出的以Kubernetes代理为核心,通过GitLab的Kubernetes集成支持基于拉的部署,这是安全性首选的部署,并迅速成为Kubernetes部署实践的流行方法。代理还支持网络安全策略集成和告警,告警可在群集中启用微调的RBAC控制。符合要求的管道配置可以通过定义可在分配了相应合规性框架的任何项目中运行的可执行管道来实施更高程度的职责分离,并降低业务风险。

同时,自定义合规框架标签,可以自定义要求,而不是PCI,HIPPA等统一性的要求求。

通过要求管理员用户在运行管理命令之前重新验证,新的管理员模式提高了对GitLab实例的安全性和控制力。

自建GitLab实例的新导出功能,使用户审核报告也变得更加容易,从而可以在一处查看用户可以访问哪些组,子组和项目。

管道编辑器可以让用户工作得更快,并保持更富有成效,一旦开始。新的“空状态”增强功能将允许新用户开始在新的空白管道文件上使用管道编辑器,而无需先创建配置文件。可以在单个作业中配置多个缓存键的功能将帮助提高管道性能,并且可以从CI/CD仪表板评估这些改进,新的DORA4图形将通过提交代码的时间来显示更改的提前期。并部署到生产中。作为相关说明,有关DevOps采用的指标现在可以在组级别使用,使用户可以了解如何采用GitLab的DevOps功能。

新的基于Semgrep的灵活规则语法以扩展和修改自定义检测规则,让GitLabSAST更加灵活和强大。通过增加了对自定义证书和密钥到期电子邮件告警的支持。现在,可以通过对Git活动强制执行SAML来改善安全状况。

新的呼叫中心计划管理在GitLab中收到的告警路由到该项目的时间表中的On-call工程师。随着安全告警日趋成熟,该计划管理将特别有用,它可提供有价值的事件管理功能,并在整个DevOps流程中具有端到端可见性。

主要功能

GitLabSaaS的GitLabKubernetes代理(PREMIUM及以上)

GitLabKubernetes代理可在GitLabSaaS上获得。通过使用代理,可以受益于对群集进行快速,基于请求的部署,而GitLabSaaS可以管理代理的必要服务器端组件。GitLabKubernetes代理是GitLabKubernetes集成的核心构建块。基于代理的集成支持基于请求的部署以及NetworkSecurity策略集成和告警,并且不久还将获得对基于推送的部署的支持。

与传统的基于证书的Kubernetes集成不同,GitLabKubernetes代理不需要向GitLab开放集群,并可围绕集群中GitLab的功能进行微调的RBAC控件。

呼叫中心时间表管理(PREMIUM及以上)

客户往往期望24/7全天候可用。当出现问题时,需要一个随叫随到的On-Call团队(或多个团队!)来快速有效地响应服务中断。

为了更好地管理压力和精疲力尽,大多数团队内部会轮流值班。GitLab的On-Call值班时间表管理功能使团队可以创建和管理通话职责的时间表。通过HTTP接口在GitLab中收到的告警将在该特定项目的时间转呼给值班工程师。

管理区管理员模式

Gitlab引入管理员模式,它可以帮助管理员从一个帐户安全地工作。当“管理模式”处于非活动状态时,管理员具有与普通用户相同的特权。在运行管理命令之前,管理员用户必须重新验证其凭据。管理员模式通过保护敏感的操作和数据来提高实例安全性。

导出用户访问报告(PREMIUM及以上)

注重合规性的企业经常需要审查其用户对公司系统和资源的访问权限。GitLab中要实现这一目标,需要使用构建自定义工具,审计相关的API以组装所需的数据。

新版本中,只需点击点击管理区域导出按钮,就可以导出成CSV文件,文件包含每个用户以及他们有权访问的组,子组和项目的列表。

在同一作业中使用多个缓存

GitLabCI/CD提供了一种缓存机制,可以在作业运行时节省宝贵的开发时间。以前,不可能在同一作业中配置多个缓存键。该限制可能导致使用工件进行缓存,或将重复的作业用于不同的缓存路径。在此版本中,提供了在单个作业中配置多个缓存键的功能。

变更指标的DORA4提前期跟踪

衡量软件开发生命周期的效率是任何组织提高DevOps使用率的重要步骤。之前,GitLab添加了API支持为更改的交付时间项目级别。这些指标可以指示吞吐量,因此可以知道提交代码并将其部署到生产环境所花费的时间。在新版本中,可以通过CI/CD仪表板在GitLabUI中访问该功能,新图表将显示更改的前置时间,并具有查看不同时间范围视图的功能,例如上周,上个月,或最近90天。并且还在组级别上添加了对该API的支持,使可以从属于该组的所有项目中获取变更指标的汇总提前期。

用于问题和合并请求的实例和组描述模板(PREMIUM及以上)

新版本中,多个项目可以使用单个仓库集中管理和获取模板。相关实例和组级别的文件模板扩展,以include发出和合并请求描述模板。当在.gitlab目录创建一个文件模板,则该模板可以用于属于该实例或组的所有项目。每个组或子组还可以设置一个附加的模板存储库,这将使来自多个文件模板存储库的模板能够级联到子组和项目。

CI/CD管道中的可选DAG(needs:)作业

GitLabCI/CD中的有向无环图(DAG)使可以使用needs语法,用于将作业配置为比其阶段更早。也支持rules,only,或者except关键字,用于确定是否将作业完全添加到管道中。但是,当needs与其他关键字一起使用时,如果未将依赖作业添加到管道中,则管道可能会失败。

在此版本中,添加optional关键字needsDAG作业的语法。如果一个依赖的工作被标记为optional但不在于管道中,needs工作会忽略它,如果工作是optional并出现在管道中needs作业等待它完成后再开始这样可以更轻松地安全组合rules,only,和except。

组级别的特定于环境的变量(PREMIUM及以上)

许多组织更喜欢在组级别指定密码和其他环境变量,因为它与团队边界或信任级别非常吻合。到目前为止,组级环境变量会影响所有环境,这在许多用例中都限制了它们的可用性。新版本中,支持组级别发布特定于环境的变量。

该更改补充了项目级别的类似功能。从现在开始,组维护者可以指定要应用给定变量的环境。

使用GitLabOperator(beta)在OpenShift和Kubernetes上部署GitLab

GitLab正在努力提供对OpenShift的全面支持。新发布了MVPGitLabOperator。用来在Kubernetes和OpenShift容器平台上管理GitLab实例的整个生命周期。不过,这一个beta版本,不建议用于生产环境。下一步将是使Operator普遍使用(GA)。将来,尽管仍会支持GitLabHelm图表,但该操作员将成为Kubernetes和OpenShift的推荐安装方法。

看板添加迭代列表

看板现在支持创建迭代列表。将问题从一个迭代快速转移迭代在计划板上到另一个,或使Epic能够在即将到来的迭代中有效地对Epic问题进行排序。

项目的活动集成现在显示在设置菜单

新版本中,活动集成显示在页面的菜单中,用户可以更清楚使用的内容,并且更容易最关心的集成。

CherryPick从fork提交给父对象

使用GitLab13.11,项目成员可以从下游分支中挑选出一些承诺,然后再将其提交回项目中。在cherry-pick对话框中添加了一个新的“Pickinproject”部分,当在提交的详细信息页面上选择“选项”“Cherry-pick”时显示。

贡献者社区可以为的项目做出贡献,团队不再需要手动下载fork的.patch文件来从陈旧或未维护的fork中获取良好的更改。

未来的增强功能包括从一个分支到另一个分支的CherryPick选择提交。

JiraConnect应用程序配置的改进

当配置用于Jira的GitLabSaaS时,可以在将可用的名称空间链接到的帐户时对其进行过滤,从而简化了可访问大量名称空间的用户的配置。

为fork中的合并请求设置默认目标项目

Fork项目后,使用合并请求为上游项目做出贡献可能会有所帮助。之前GitLab假定来自fork项目的合并请求将始终以上游项目为目标。这可能会导致不应该在上游进行代码合并的错误步骤,或者用户需要在打开合并请求之前进行更改。

新版本中,GitLab现在支持在fork项目中创建的合并请求设置默认目标项目。

违反代码质量的程度按严重性排序

在项目上运行代码质量扫描可以发现数十到数千个违规。在“合并请求”小部件的较小视图中,当通过大量代码质量违规排序时,可能很难先确定最关键的问题要首先解决。

新版本中,“代码质量合并请求”小部件和“完整代码质量报告”默认均按严重性对违规进行排序,以便可以快速识别要解决的最重要的代码质量违规。

版本控制Composer依赖项

下载

下载Composer依赖项时有两个选项:source或dist。对于稳定版本,dist默认情况下,Composer使用并将依赖项下载为zip文件。但是,也可以直接从版本控制中下载它。如果启用--prefer-source,Composer会将依赖项下载为Git克隆而不是打包的zip文件。如果要为项目进行错误修复并直接获取依赖项的本地Git克隆,这将很有用。

直到最近,还无法在下载Composer依赖项时使用prefer-source和相关的preferred-install命令和配置。这使许多人无法将GitLab软件包注册表使用Composer依赖项。

新版本中,可以使用--prefer-source从源代码下载Composer依赖项:

1
查看完整版本: GitLab1311增加K8S代理和管