Skip to main content

· 14 分钟阅读

Choerodon 猪齿鱼作为全场景效能平台,是基于Kubernetes,Istio,knative,Gitlab,Spring Cloud来实现本地和云端环境的集成,实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。

2020年10月14日,Choerodon猪齿鱼发布0.23版本,本次更新在平台首页新增工作台功能,并在增加了项目概览页面,新增了制品库、代码库等功能,应用流水线中新增了CD属性的阶段,欢迎各位更新体验。

  • 发布版本:0.23
  • 发布时间:2020年10月14日
  • 更新范围:敏捷协作、代码开发、环境部署、制品库、代码库以及基础功能

下面就为大家带来详细的模块介绍。

敏捷协作

功能优化

工作列表

  • 优化所有问题一键展开。
  • 优化工作列表筛选。

缺陷修复

  • 修复问题详情创建分支报错的问题。

代码开发

新增功能

  • 应用流水线中新增CD属性的阶段,支持在其中添加CD类型的任务,如:部署、主机部署、人工卡点

  • 应用流水线中新增支持“正则匹配”、“精确匹配”、“精确排除”的触发分支匹配方式
  • 应用流水线中新增“上传jar包至制品库”的步骤,支持将同一任务中构建生成的jar包上传至指定的目标制品库
  • 应用流水线中新增“Maven发布”的步骤,支持构建工件并上传至项目下指定的目标制品库

  • 应用流水线-CI阶段-mvn构建步骤-setting配置部分,新增支持选择项目下已有的依赖库。
  • 应用流水线-CI阶段-代码检查类型的任务中新增SonarQube的默认配置
  • 应用流水线中新增CI变量配置的功能,支持项目所有者在此配置全局CI变量或某条流水线的CI变量,以便之后开发人员在添加流水线CI任务时引用
  • 应用流水线-构建类型任务-高级设置中,新增共享目录设置的功能,支持同一流水线中的构建任务在共享目录中上传或下载产生的工件或其他文件内容
  • 应用流水线中新增Runner配置的指引界面
  • 项目成员新增支持更多的GitLab权限,包括:Guest、Reporter、Developer和Maintainer,且拥有不同GitLab权限的项目成员在应用服务、代码管理、CI流水线菜单下的操作权限不同,从而使项目成员角色能适应更多的项目开发与管理场景
  • 项目所有者在应用服务模块中修改应用服务时,支持选择项目层已有的自定义Docker仓库

功能优化

  • 应用流水线docker构建步骤中新增设置是否进行证书校验,用于解决自签名证书校验不通过的问题

缺陷修复

  • 修复了应用流水线中,项目成员没有应用服务的权限,可以看到该服务对应的CI流水线的问题
  • 修复了组织管理员同时拥有项目成员角色, 被删除组织管理员角色后, 项目层应用服务权限不正常的问题

移除

  • 移除了应用服务详情中“权限分配”Tab页面,点击权限管理按钮后,将跳转至代码库管理页面

环境部署

新增功能

  • PV管理中新增LocalPV类型的PV

缺陷修复

  • 修复了无法收到资源删除验证的通知的问题
  • 修复了应用流水线执行记录页面中部署任务的生成实例显示问题
  • 修复了停用Pod之后,还能增减Pod数量的问题
  • 修复了一次部署可能产生多条部署记录的问题
  • 修复了实例的唯一性校验为全局唯一的问题,改为了集群下唯一
  • 修复了同名版本生成时更新了chart包但是没有更新数据库values内容的问题

功能优化

  • 在集群中安装监控组件时,增加“是否安装https”的选项,且默认为否,用以解决集群未安装证书时,监控组件无法使用的问题
  • 优化了chart包的values文件获取,目前使用广度优先搜索, 多个层级包含values文件时, 会取最高层
  • 优化了Pod数量置为1后,不能再降为0的提示;此时,鼠标hover至灰色的减少Pod的角标后,显示出:若想降至0,请直接点击“停用实例”
  • 优化了流水线中创建部署任务时自动填充实例名称的步骤
  • 优化了部署配置的创建步骤,没有生成过版本的应用服务也能创建部署配置

制品库

新增功能

  • 制品库管理:创建制品库(docker、maven、npm)、自定义harbor仓库、自定义nexus服务、仓库总览、镜像/包列表管理、用户权限管理、操作日志等功能

  • 平台层新增"制品库管理"模块,包括为默认的nexus服务上,已有仓库的分配功能
  • 自定义nexus服务功能: 支持添加默认外自己安装的nexus服务。创建maven/npm仓库时,是在对应启用的nexus服务下
  • 创建制品库功能: 支持在当前项目下创建/更新制品仓库

  • 镜像/包管理功能: 支持查看与发布仓库下镜像/包列表
  1. 镜像列表

  2. maven包列表

  • 用户权限功能: 支持管理项目成员对该仓库的权限
  • 操作日志功能: 记录了权限分配/镜像操作的操作日志
  • 制品库账号:查询默认密码、修改密码

代码库

新增功能

  • 项目层新增"代码库管理"模块,包括权限分配、权限申请/审批、权限审计、安全审计、保护分支/标记、操作日志、总览等功能

  • 组织层新增"代码库管理"模块,包括权限分配、权限审计、操作日志等功能

  • 权限分配功能支持查看和分配团队成员的代码库权限
  • 权限申请功能支持向项目管理员申请应用服务的权限
  • 权限审计功能支持定时审计代码库与Gitlab权限不一致的数据, 并支持修复不一致权限
  • 安全审计功能支持查看团队成员的权限分布情况
  • 保护分支/标记支持查看和设置保护分支和保护标记, 用于对分支(branches)和标记(tags)的权限进行设置
  • 操作日志功能记录了权限分配的操作日志
  • 总览功能支持查看各应用服务的一些信息

基础功能

新增功能

  • 平台首页新增工作台功能,支持查看用户在所有项目下的待办问题、待审核任务、项目最近更新文档、项目与个人快速链接以及最近访问的应用服务与环境

  • 平台层新增平台开发者的预定义角色,支持该角色查看操作平台层事务、任务以及API相关的菜单
  • 项目层新增项目概览

  • 项目列表中新增星标收藏项目的功能,支持在首页工作台中快速进入星标项目

缺陷修复

  • 修复了组织层-客户端添加角色,页面无反应的问题
  • 修复了组织层-客户端分配角色时能选择已停用角色的问题
  • 修复了组织层Logo修改后未生效的问题
  • 修复了“用户管理-修改用户”与“个人信息-修改信息”中,14开头手机校验失败的问题
  • 修复了更新用户角色时去掉所有角色, GitLab未同步的问题
  • 修复了平台管理-消息日志”中,过滤表搜索报错的问题
  • 修复了接收设置页面中过滤表搜索栏,搜索过滤无效果的问题
  • 修复了企业微信类型的webhook在Webhook记录中显示偶现为JSON类型的问题
  • 修复了webhook记录详情中的”消息内容“模块为空的问题
  • 修复了asgard服务的事务刷新不进去的问题

功能优化

  • 优化完善了平台的安全性相关的模块,提高了平台的安全性
  • 优化了个人中心-接收设置界面卡顿的问题
  • 优化了修改用户界面手机号为必填的问题
  • 优化了项目列表中,各项目栏内项目名称的可点击范围太大从而引起误触的问题

移除

  • 移除了“组织层-管理中心-仓库”界面中Docker仓库配置的入口

社区参与

感谢以下朋友在社区论坛中提出反馈和意见,在0.23版本更新中作出贡献,感谢大家一直以来的支持。

@hyland

@wangbo

更加详细的内容,请参阅Release Notes和官网用户手册。

安装文档:http://choerodon.io/zh/docs/installation-configuration/steps/

升级文档: http://choerodon.io/zh/docs/installation-configuration/update/0.22-to-0.23/

欢迎各位朋友通过Choerodon的GitHub和猪齿鱼社区进行反馈与贡献,帮助Choerodon猪齿鱼不断成长。Choerodon会持续优化,敬请期待。

-▼-

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:

Choerodon猪齿鱼官方社区用户交流群,此群可交流猪齿鱼使用心得、Docker、微服务、K8S、敏捷管理等相关理论实践心得,群同步更新版本更新等信息,大家可以加群讨论交流。

①-Choerodon猪齿鱼官方交流(已满);

②-Choerodon猪齿鱼官方交流(可加);【微信号发至客服邮箱[email protected],运营同事拉您入官方交流群】

欢迎加入Choerodon猪齿鱼社区,共同为企业数字化服务打造一个开放的生态平台。

· 15 分钟阅读

原文作者:Jeff Hale

原文地址:https://towardsdatascience.com/15-docker-commands-you-should-know-970ea5203421

翻译:付新圆

在这篇文章中,我们将学习15个Dockers CLI命令。如果你还不了解Docker,请查看这个系列的其他部分进行学习,Docker概念生态系统DockerfileDocker映像

Docker 命令约有十亿个(给或接受十亿个)。Docker 文档范围很广泛,但当您刚入门时,文档会非常庞大让你不知所措。在这篇文章中,我将重点介绍运行Docker的关键命令。

图:水果主题

之前的文章我们都把文章的主题隐喻成食物,这里让我们使用水果主题。蔬菜在关于减肥的文章中提供了营养。现在,美味的水果将为我们提供营养,因为我们学习的是关键 Docker 命令。

概述

回想一下,Docker 映像是由 Dockerfile +任何必要的依赖项组成的,还要记得 Docker 容器是一个 Docker 映像。若要使用 Docker 命令,首先需要知道您处理的是映像还是容器。

  • Docker 映像要么存在,要么不存在;
  • Docker 容器要么存在,要么不存在;
  • 存在的 Docker 容器要么正在运行,要么未运行。

当您知道正在处理什么,就可以找到适合该工作的命令。

共同点

以下是关于Docker命令需要了解的一些信息:

  • Docker CLI 管理命令从Docker开始,然后是空间,然后是管理类别,然后是空间,然后是命令。例如,dockerdocker container stop停止一个容器。
  • 引用特定容器或映像的命令需要该容器或映像的名称或 ID。

例如, docker container run my_app 是生成和运行名为 "my_app"的命令。在整个示例中,我将使用 my_container  这个名称来表示泛型容器,my_image,my_tag等等也一样。

如果适用,我将单独提供命令,然后使用公共标志。前面有两个破折号的标记是该标志的全名。具有一个破折号的标记是完整标志名称的快捷方式。例如,

-p--port缩写的标志。

图:标志提供命令选项

目标是将这些命令和标志留在您的记忆中,并作为本指南的参考。本指南适用于Linux和Docker Engine 18.09.1版和API 1.39版。

首先,我们将查看容器的命令,然后再查看映像的命令。下一篇文章将介绍卷。下面是15个命令的列表 – 加上3个附加命令!

容器

使用docker container my_command

create— 从映像创建容器

start— 启动现有容器

run—创建新容器并启动它

ls— 列出正在运行的容器

inspect— 查看有关容器的大量信息

logs— 打印日志

stop— 优雅地停止运行容器

kill—突然停止容器中的主进程

rm—删除已停止的容器

映像

使用docker image my_command

build— 生成映像

push— 将映像推送到远程注册表

ls— 列出映像

history— 请参阅中间映像信息

inspect— 查看大量有关映像的信息,包括图层

rm— 删除映像

其他

docker version—列出有关 Docker 客户端和服务器版本的信息

docker login—登录到Docker注册表

docker system prune—删除所有未使用的容器、未使用的网络和悬空映像

容器

容器开始

在日常生活中,术语create、start和run都有相似的语义。但每个命令都是一个单独的 Docker 命令,用于创建和/或启动一个容器。让我们先看看创建一个容器。

docker container create my_repo/my_image:my_tag-从映像创建容器。

我将缩短my_repo/my_image:my_tagmy_image文章的其余部分。

有很多可能的标记,你可以传递给create

docker container create -a STDIN my_image

-a--attach的简短。将容器连接到 STDIN、STDOUT 或 STDERR。

现在,我们已经创建了一个容器,让我们开始它。

docker container start my_container-启动现有容器。

请注意,容器可以通过容器的 ID 或容器的名称引用。

docker container start my_container

图:开始

现在您已经知道如何创建和启动容器了,让我们来谈谈最常见的 Docker 命令。它将create

start合并为一个命令:run

docker container run my_image-创建新容器并启动它。它也有很多选择,让我们看看几个。

docker container run -i -t -p 1000:8000 --rm my_image

-i--interactive的缩写。即使未连接,也要保持 STDIN 打开。

-t--tty的缩写。分配一个伪终端,将终端与集装箱的STDIN和STDOUT连接。

您需要同时指定-i-t,然后通过终端外壳与容器进行交互。

-p--port的缩写。端口是与外部世界的接口。1000:8000将Docker端口8000映射到计算机上的端口1000。如果你有一个应用程序可以将某些内容输出到浏览器中,那么你可以将浏览器导航到本地主机localhost:1000并看到它。

--rm当容器停止运行时,自动删除该容器。

让我们看一些更多的例子。run

docker container run -it my_image my_command

sh是可以在运行时指定的命令。sh将在容器内启动 shell 会话,您可以通过终端与之交互。对于Alpine映像,shbash更好,因为Alpine映像没有安装bash。键入exit结束交互式shell会话。

请注意,我们将-i-t合并到-it中。

docker container run -d my_image

-d--detach的缩写。在后台运行容,。允许您在容器运行时将终端用于其他命令。

检查容器状态

如果您正在运行 Docker 容器,并且想要了解要与哪个容器交互,则需要列出它们。

docker container ls-列出正在运行的容器,还提供有关容器的有用信息。

docker container ls -a -s

-a-all的缩写,列出所有容器(不只是正在运行的容器)。

-s--size的缩写,列出每个容器的大小。

docker container inspect my_container-查看有关容器的大量信息。

docker container logs my_container-打印容器的日志。

图:日志。不确定虚拟日志的关联性,也许通过大量的纸张?

容器结束

有时需要停止正在运行的容器。

docker container stop my_container-正常停止一个或多个正在运行的容器。在容器关闭前给出10 秒的默认值,以完成任何进程。

或者,如果您不耐烦:

docker container kill my_container-突然停止一个或多个正在运行的容器。就像扒掉电视插头一样。在大多数情况下,stop是最好的选择。

docker container kill $(docker ps -q)-关闭所有正在运行的容器。

图:杀死的蟑螂

然后删除容器,包括:

docker container rm my_container-删除一个或多个容器。

docker container rm $(docker ps -a -q)-删除所有未运行的容器。

这些就是 Docker 容器的八个基本命令。

回顾一下,首先创建一个容器,然后,启动容器;或将这些步骤与docker run my_container结合。然后,你的应用将运行。

然后,使用docker stop my_container停止容器;最终使用docker rm my_container删除容器。

现在,让我们来看看制造称为映像的模具的神奇容器。

映像

下面是用于处理 Docker 映像的七个命令。

开发映像

docker image build -t my_repo/my_image:my_tag .-从位于指定路径或URL的Dockerfile构建名为my_image的Docker映像。

-t是标记的简短。告诉 Docker 使用提供的标记来标记映像。在my_tag这种情况下。

.命令末尾的 (期间) 告诉 Docker 在当前工作目录中根据 Dockerfile 生成映像。

图:构建它

构建映像后,您需要把它推到远程注册表,以便使它被共享并根据需要被拉取。假设您要使用Docker Hub,请转到浏览器中并创建一个帐户。它是免费的。

下一个命令不是映像命令,但在这里查看很有用,所以我要提一下。

docker login-登录到 Docker 注册表,提示时输入用户名和密码。

图:推

docker image push my_repo/my_image:my_tag-将映像推送到注册表。

一旦有一些映像,你可能检查他们。

检查映像

图:检查时间

docker image ls-列出您的映像。显示每个映像的大小。

docker image history my_image-显示映像的中间映像其大小及创建方式。

docker image inspect my_image-显示大量有关映像的详细信息,包括组成映像的图层。

有时您需要清理映像。

删除映像

docker image rm my_image-删除指定的映像。如果映像存储在远程存储库中,则该映像仍将在那里可用。

docker image rm $(docker images -a -q)-删除所有映像。请注意,已推送到远程注册表的映像将保留,这是注册表的好处之一。

以上讲述了大多数必不可少的 Docker 映像相关命令。我们将在下一篇文章中介绍与数据相关的命令。

图:命令就像水果, 营养丰富, 美味可口。

其他

docker version-列出有关 Docker 客户端和服务器版本的信息。

docker login-登录 Docker 注册表。提示时输入用户名和密码。

docker system prune出现在下一篇文章中。Twitter 和 Reddit 上的读者认为,加入这个列表是件好事。

docker system prune-删除所有未使用的容器、未使用的网络和悬空映像。

docker system prune -a --volumes

-a--all的缩写。删除未使用的映像,而不仅仅是悬空的映像。

--volumes删除未使用的卷。我们将在下一篇文章中讨论更多有关卷的文章。

管理命令

在 CLI 1.13 Docker 中引入了按逻辑分组并一致命名的管理命令名称。旧命令仍然有效,但新命令使使用 Docker 更容易。本文的原始版本列出了旧名称。我更新了文章,根据读者建议使用管理命令名称。请注意,此更改仅引入两个命令名称更改 - 在大多数情况下,它只是意味向命令添加containerimage。这里是命令的映射。

如果您刚刚开始使用 Docker,以下是三个最重要的命令:

docker container run my_image-创建新容器并启动它。你可能想要一些标志在这里。

docker image build -t my_repo/my_image:my_tag .-生成映像。

docker image push my_repo/my_image:my_tag-将映像推送到远程注册表。

下面是基本 Docker 命令的较大列表:

容器

使用docker container my_command

create-从映像创建容器

start-启动现有容器

run-创建新容器并启动它

ls-列出正在运行的容器

inspect-查看有关容器的大量信息

logs-打印日志

stop-优雅地停止运行容器

kill-突然停止容器中的主要过程

rm-删除已停止的容器

映像

使用docker image my_command

build-生成映像。

push-将映像推送到远程注册表

ls-列出映像

history-请参阅中间映像信息

inspect-查看大量有关映像的信息,包括图层

rm-删除映像

其他

docker version-列出有关 Docker 客户端和服务器版本的信息

docker login-登录到 Docker 注册表

docker system prune-删除所有未使用的容器、未使用的网络和悬空映像。

若要在使用 Docker 时查看 CLI 引用,只需在命令行中输入命令。

现在,您就可以使用 Docker 构建东西了!

结尾

如果您错过了本系列的早期文章,请查看它们。第一个是:Docker-第1部分:什么是Docker?

希望这些文章对您有帮助。

· 11 分钟阅读

角色管理是一个平台或系统中重要的基础功能,其中角色是一组特定权限的集合,而管理员可通过给成员分配角色来赋予成员相应的权限。这是角色在各个平台中的基本用法。

考虑到平台的业务层级与结构,Choerodon 的角色管理功能在此基础上,将角色按照层级进行了划分。分为:平台层、组织层与项目层,且一个角色仅能对应为一个层级。

本文旨在介绍 Choerodon 猪齿鱼V0.22及之后版本中组织层的角色管理功能。

Choerodon的角色体系与结构

Choerodon RBAC结构

对于各个平台或系统来说,权限系统设计得越全面和精细,后期的系统扩展性就越高。所以Choerodon采用了RBAC(Role-Based Access Control)的权限模型,基于角色来进行权限控制。通过角色关联用户,角色关联权限的方式间接赋予用户权限。以下为Choerodon RBAC的架构图。

除了结构上的优点,RBAC还支持3个著名的安全原则:

  1. 最小权限原则:最小权限原则之所以被RBAC所支持,是因为RBAC可以将其角色配置成其完成任务所需要的最小的权限集。因此在Choerodon中创建自定义角色时,为其分配满足条件的最小权限集合即可。

  2. 责任分离原则:责任分离原则指的是,可以通过调用相互独立互斥的角色来共同完成敏感的任务而体现,比如要求一个计帐员和财务管理员共参与同一过帐。由于Choerodon应用场景偏向项目管理、团队协作以及敏捷开发,因此对于角色的责任分离暂无特别的应用场景。

  3. 数据抽象原则:可以通过权限的抽象来体现,如:项目开发管理者和项目开发人员两个角色,对于“开发-应用服务”界面中的查看与操作权限就存在差异,而我们只需为项目开发人员这个角色分配页面的可读权限即可。

Choerodon RBAC流程

在开头我们提到了,Choerodon 的角色管理体系中,将角色按照层级进行了划分。分为:平台层、组织层与项目层,且一个角色仅能对应为一个层级。以下为Choerodon中各层级角色的整体流程图。

预定义角色

Choerodon猪齿鱼在组织层与项目层均设有预置角色,用于满足一般的组织与项目结构;其中包括:组织管理员、组织成员、项目所有者与项目成员。

  • 组织层

组织管理员:是组织的管理者,用于管理组织的基础配置以及所有其中所有的项目。

组织成员:该角色用于衔接组织层与项目层,支持组织成员在所属组织下创建项目。

  • 项目层

项目所有者:项目的管理者与所有者,可直接管理项目下所有的团队成员及项目资源。

项目成员:项目团队成员,可在项目下管理自己的进度以及负责的模块。

自定义角色

在预定义角色的基础上,为了满足更多的应用场景,Choerodon支持组织管理员在“管理中心-角色管理”页面,创建组织层或项目层的自定义角色,并且为这些自定义角色分配各个菜单的查看或操作权限。

比如从普通研发团队的角度来看,便可在项目下为“产品经理”、“测试人员”等业务人员创建相关的自定义角色,并在项目下为其分配相关菜单及接口的权限,以此来避免预置的“项目成员”角色菜单权限过多的问题。

如何使用Choerodon进行角色管理

自0.22版本后,Choerodon支持平台内各组织根据实际使用场景维护各自的角色,并为其分配对应的权限。以下为 Choerodon 中管理角色的具体步骤(此处以创建组织层角色为例,若想创建项目层角色,步骤类似)。

创建角色

组织管理员可在”管理中心>角色管理“菜单中,点击操作栏的“创建组织角色”按钮,即可在此创建新角色,在创建过程中需手动维护:

  • 角色编码:角色编码具有唯一性,是角色的标识。

  • 角色名称:角色的名称可根据角色权限与功能来定义。

  • 角色权限:创建组织角色时,用户可以在此为角色分配组织层各菜单的访问权限;且支持为角色分配其中各个操作按钮或接口的权限,来实现更细颗粒的权限管理。

角色创建成功后,便能在主页管理界面中看到该角色相关的基础信息;而组织管理员也能在“用户管理”页面为组织下的用户分配创建成功的自定义角色。

Choerodon中支持为用户添加多个角色,而用户的权限为所分配角色的并集。

修改角色

对于创建成功的自定义角色,组织管理员可对其进行修改;在列表中点击目标角色的角色名称,进入修改角色页面。

其中,角色编码作为角色的唯一标识,不允许修改。组织管理员可在此对所选角色的名称或权限进行修改,以此来灵活地控制该角色对应的用户在平台中的菜单权限或操作权限。

Choerodon 预定义角色不支持修改。

启停用角色

  • 停用角色:当组织中不再需要某个角色,想将其回收,便直接在此将其停用即可。停用角色后,赋予该角色的权限将失效,且已被分配该角色的成员对应的权限也将失效;而后续对用户分配角色时,也将不再显示该角色。
  • 启用角色:自定义角色被停用后,可以再次启用。启用角色后,角色状态变为'启用'。而赋予该角色的权限也随之生效。

预定义角色不可停用,只能启/停用自定义角色。

总结

本文介绍了Choerodon中组织层的角色管理功能,至于平台层的角色管理功能,由于在0.22版本后,与Hzero进行了融合,因此支持了更多角色相关的功能(平台管理员可以在”平台层-用户管理“页面管理平台中所有的角色),从而能满足更多的场景;而我们将在后续的文章对其进行详细的介绍。

关于猪齿鱼

Choerodon 猪齿鱼作为全场景效能平台,是基于Kubernetes,Istio,knative,Gitlab,Spring Cloud来实现本地和云端环境的集成,实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。

更加详细的内容,请参阅Release Notes官网

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:

Choerodon猪齿鱼官方社区用户交流群,此群可交流猪齿鱼使用心得、Docker、微服务、K8S、敏捷管理等相关理论实践心得,群同步更新版本更新等信息,大家可以加群讨论交流。

①-Choerodon猪齿鱼官方交流(已满);

②-Choerodon猪齿鱼官方交流(可加);【微信号发至客服邮箱[email protected],运营同事拉您入官方交流群】

欢迎加入Choerodon猪齿鱼社区,共同为企业数字化服务打造一个开放的生态平台。

· 13 分钟阅读

原文作者:Jeff Hale

原文地址:https://towardsdatascience.com/slimming-down-your-docker-images-275f0ca9337e

翻译:付新圆

在本文中,您将学习如何加快Docker构建周期并创建轻量级映像。遵循之前的文章中的食物隐喻,我们将沙拉隐喻为Docker映像,同时减少Docker映像的数量。

在本系列的第3部分中,我们介绍了十几个Dockerfile指令。如果您错过了,请在这里查看文章:

《Docker-第3部分:十二个Dockerfile指令》

FROM—指定基本(父)图像。

LABEL—提供元数据,包括维护者信息。

ENV—设置持久性环境变量。

RUN—运行命令并创建图像层,用于将软件包安装到容器中。

COPY-将文件和目录复制到容器。

ADD-将文件和目录复制到容器,可以支持本地.tar文件。

CMD—为执行中的容器提供命令和参数,可以覆盖参数,只能有一个CMD。

WORKDIR—为以下说明设置工作目录。

ARG—定义在构建时传递给Docker的变量。

ENTRYPOINT—为执行中的容器提供命令和参数。争论依然存在。

EXPOSE—暴露端口。

VOLUME—创建目录安装点以访问和存储持久数据。

现在让我们来看看如何设计Dockerfiles,以节省开发映像和拉取容器时的时间。

缓存

Docker的优势之一是它提供了缓存,帮助您更快地迭代映像构建。

构建映像时,Docker会按顺序执行每一个Dockerfile中的指令。在检查每个指令时,Docker在其缓存中寻找一个现有的中间映像,该中间映像可以重复使用,而不是创建一个新的(重复的)中间映像。

如果缓存失效,则使缓存失效的指令和所有后续的Dockerfile指令都会生成新的中间映像。一旦缓存失效,Dockerfile中的其余指令就都失效了。

因此,从Dockerfile的顶部开始,如果基本映像已经在缓存中,就会重复使用它。否则,缓存将失效。

图:击中

然后,将下一条指令与从该基本映像派生的缓存中的所有子映像进行比较。比较每个缓存的中间映像,以查看指令是否找到缓存命中。如果是缓存未命中,则缓存无效。重复相同的过程,直到到达Dockerfile的末尾。

大多数新指令都只是与中间图像中的指令进行比较。如果存在匹配项,则使用缓存的副本。

例如,当RUN pip install -r requirements.txt在Dockerfile中找到一条指令时,Docker会在其本地缓存的中间映像中搜索同一条指令,不比较旧的和新的requirements.txt文件的内容。

如果您更新要求,则此行​​为可能会出现问题requirements.txt带有新软件包的文件并使用RUN pip install并使用新的软件包名称重新运行软件包安装。我将在稍后展示一些解决方案。

与其他Docker指令不同,ADD和COPY指令需要Docker查看文件的内容,以确定是否存在缓存命中。将引用文件的校验和与现有中间映像中的校验和进行比较。如果文件内容或元数据已更改,则缓存失效。

下面是一些有效使用缓存的技巧:

  • 可以通过传递--no cache=True关闭docker build
  • 如果要对指令进行更改,则随后的每一层都将被频繁重建。要利用缓存,请在Dockerfile中放置可能变化尽可能小的指令。
  • ChainRUN apt-get updateapt-get install命令以避免缓存未命中问题。
  • 如果使用的是包安装程序(如pip)并带有requirements.txt文件,则请遵循以下模型,以确保您不会因使用requirements.txt中列出的旧软件包而收到陈旧的中间映像。
CCOPY requirements.txt /tmp/
RUN pip install -r /tmp/requirements.txt
COPY . /tmp/

这些是有效使用Docker构建缓存的建议。

缩小尺寸

Docker映像会变大,所以需要将它们保持的较小,以便可以快速拉出来并使用很少的资源。

让我们瘦下来的物品!

图:沙拉

Alpine基本映像是一个完整的Linux发行版,没有太多其他内容。下载通常小于5MB,但它需要花费更多的时间来编写构建一个工作应用程序所需的依赖项的代码。

图:阿尔卑斯山

如果您的容器中需要Python,则可以使用Python Alpine构建。它包含Linux和Python,其他大部分都由您提供。

使用最新的Python Alpine构建并带有print(“ hello world”)脚本构建的图像重78.5 MB,这是Dockerfile:

FROM python:3.7.2-alpine3.8
COPY . /app
ENTRYPOINT [“python”, “./app/my_script.py”, “my_var”]

在Docker Hub网站上,基本映像被列为29 MB。构建子映像后,它会下载并安装Python,使其变得更大。 除了使用Alpine基本映像外,另一种减小图像大小的方法是使用多级构建,该技术技术增加了Dockerfile的复杂性。

多阶段构建

图:一个阶段+另一个阶段=多阶段

多级构建使用多个FROM指令。您可以有选择地将文件(成为构建工件)从一个阶段复制到另一个阶段,可以在最后的图像中留下任何你不想要的内容。此方法可以减小整体图像大小。

每个FROM指令

  • 开始构建的新阶段;
  • 保留了先前阶段中创建的任何状态;
  • 可以使用其他基础;

以下是Docker docs中多级构建的修改示例:

FROM golang:1.7.3 AS build
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html  
COPY app.go .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .
FROM alpine:latest  
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=build /go/src/github.com/alexellis/href-counter/app .
CMD ["./app"]

注意,我们通过在FROM指令后添加名称来命名第一阶段。然后,COPY --from=稍后在Dockerfile 中的指令中引用命名的阶段。 多阶段构建在某些情况下是有意义的,可以在生产中制造大量的容器。多级构建可以从图像大小中挤出最后一盎司(如果用公制计算的话,则为克)。但是,有时多级构建会增加复杂性,使图像难以维护。

相比之下,每个人都应该使用.dockerignore文件来帮助保持其Docker映像的外观。

.dockerignore

.dockerignore文件是您应该知道的一些知识。

.dockerignore类似于.gitignore。这是一个包含模式列表的文件,Docker可以使用这些模式与文件名进行匹配,并在制作映像时将其排除。

图:.dockerginore

将.dockerginore文件与Dockerfile和其他构建上下文放在同一个文件夹中。

当您运行docker build创建映像时,Docker会检查.dockerignore文件。如果找到一个,它将逐行遍历文件并使用Go的filepath.Match规则 ,以及Docker的一些规则,匹配要排除的文件名考虑Unix风格的glob模式,而不是正则表达式。

因此*.jpg将排除扩展名为.jpg的文件,并且videos将排除视频文件夹及其内容。

您可以用以#开头的注释来解释您在.dockrignore中所做的工作。

使用.dockergnore从Docker映像中排除不需要的文件是一个好方法。.dockerignore可以:

  • 帮助你保守秘密。没有人想要在图像中输入密码。
  • 缩小图像大小。更少的文件意味着更小更快的图像。
  • 减少生成缓存失效。如果日志或其他文件正在更改,而您的映像因此而使其缓存失效,则会减慢构建周期。

这些就是使用.dockerignore文件的原因。

尺寸检查

如何从命令行找到Docker图像和容器的大小。

  • 要查看正在运行的容器的大致大小,可以使用命令docker container ls-s
  • 运行docker image ls显示图像的大小。
  • 要查看构成您的图像的中间图像的大小docker image history my_``image:my_tag
  • 运行docker image inspect my_``image:tag将显示有关图像的许多信息,包括每一 层的大小。图层与构成整个图像的图像有细微的不同。但在大多数情况下,你可以把它们看作是相同的。
  • 安装和使用dive包可以很容易地查看层内容。

现在,让我们看一些简化操作的最佳实践。

八种减少图像大小和构建时间的最佳实践

  1. 尽可能使用官方的基本图像。官方图片定期更新,比f非官方图片更安全;
  2. 尽可能使用Alpine图像,以保持图像的轻量化。
  3. 如果使用apt,请在同一条指令中结合RUN apt get update和apt get install,然后在该指令中链接多个软件包。用\字符在多行按字母顺序列出包。例如:
RUN apt-get update && apt-get install -y \
    package-one \
    package-two 
 && rm -rf /var/lib/apt/lists/*

这种方法减少了要构建的层数,并保持了事物的整洁。

  1. 在RUN指令的末尾包含&& rm -rf /var/lib/apt/lists/*,以清理apt缓存,使其不存储在层中。

  2. 通过在Dockerfile中较低位置的指令来使用缓存。

  3. 使用.dockerignore文件将不需要的和不必要的文件排除在图像之外。

  4. 检查 dive - 一个非常酷的工具,用于检查Docker图像层。

  5. 不要安装不需要的软件包。

结尾

以上就是Docker映像快速构建,以及快速下载并且不占用太多空间的内容。学习是成功的一半。在本系列的下一篇文章中,将深入探讨基本的Docker命令,希望对你有帮助。

· 10 分钟阅读

Choerodon 猪齿鱼作为全场景效能平台,是基于Kubernetes,Istio,knative,Gitlab,Spring Cloud来实现本地和云端环境的集成,实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。

2020年8月17日,Choerodon猪齿鱼发布 0.22 版本,本次更新Choerodon 框架类型的使用的功能与 HZERO 开源框架进行了融合,系统的平台层和组织层的菜单结构有所调整。

项目层新增了普通敏捷项目和运维项目两种项目类型,代码开发模块新增“CI流水线”的功能,其它功能模块也都进行了不同程度的修改和优化,如平台功能、协作、部署等,欢迎各位更新体验。

  • 发布版本:0.22
  • 发布时间:2020年8月17日
  • 更新范围:敏捷协作、代码开发、测试管理、环境部署以及基础功能和底层组件服务

下面就为大家带来详细的模块介绍。

基础功能

新增功能

  • 组织层“管理中心”新增Webhook配置功能,支持创建钉钉、企业微信、Json类型的Webhook来发送组织层的消息通知;
  • 组织层“管理中心”与项目层“设置-通知”模块新增Webhook执行记录页面,支持查看与重试某条Webhook执行记录;
  • 组织层“管理中心”新增“角色管理”的功能,支持组织管理员在此创建组织层或项目层的自定义角色;

  • “平台层-消息服务”中新增组织层与项目层中各个事件对应的钉钉、企业微信、Json类型webhook的默认消息模板;
  • 新增“普通敏捷项目”项目类型,此类项目仅保留了敏捷测试相关的功能,支持项目团队专注使用敏捷协作功能;
  • 新增“运维项目”项目类型,此类项目仅保留了开发部署等DevOps相关的功能;

功能优化

  • 平台概览界面中新增了显示平台中集群状态与数量的情况;
  • “平台管理-邮件日志”中,支持重发“成功”或“失败”状态的邮件;
  • “平台管理-邮件日志” 中,支持自动清除半年前的发送记录;
  • “组织层-用户管理-添加组织用户”、“项目层-团队成员-添加团队成员”时,在搜索出的用户后面,加上了登录名;
  • “平台管理-接口”页面的“权限编码”与“地址”后面加上了快速复制的按钮;

敏捷协作

新增功能

迭代计划、工作列表

  • 工作列表-所有 问题 按issue层级展示;

  • 工作列表-所有问题支持批量修改issue;

  • 工作列表-所有问题支持全部字段筛选,包括全部预定义字段、自定义字段;
  • 敏捷看板支持全屏显示;
  • 敏捷看板支持查看多个迭代;
  • 导入问题支持按照任务-子任务、故事-子任务父子层级导入;
  • 导出问题支持按问题层级导出;
  • 敏捷看板支持自定义状态顺序;
  • 敏捷消息添加预置钉钉、企业微信webhook模板 ;

缺陷修复

迭代计划、工作列表

  • 修复状态机状态删除造成看板异常的问题;

功能优化

迭代计划、工作列表

  • 待办事项史诗侧栏优化为不显示已完成史诗;
  • 优化子任务详情页:可以直接看到父级任务的概要;
  • 优化敏捷服务权限;
  • 优化导出问题性能问题;
  • 优化待办事项团队成员工作量显示;

知识库

  • 知识库文档编辑器npm包升级

代码开发

新增功能

  • 开发模块新增“CI流水线”的功能,支持创建多个阶段,且每个阶段中可添加多个任务;

  • CI流水线界面中支持配置添加多种类型的任务,包括:构建、代码检查与自定义任务;
  • CI流水线中新增支持多种常用语言的构建模板:如Maven模板、Npm模板、Go模板;
  • CI流水线界面中支持查看各条CI流水线的执行记录详情;

缺陷修复

  • 修复了导入应用服务时,选择的微服务后端模板中使用命令启动错误的问题;

测试管理

缺陷修复

  • 修复创建计划时间校验问题;
  • 修复查看用例详情由于objectnumber造成偶发报错问题;

环境部署

新增功能

  • “应用部署-资源-域名”模块,创建与修改域名时,新增支持填写“Annotation”;
  • C7N agent中helm组件由V2升级至V3;
  • 升级部署模块支持的k8s版本至V1.17;

缺陷修复

  • 修复了未登录Grafana时,节点监控页面白屏的问题;
  • 修复了点击实例界面“运行详情-更多详情”偶现白屏的问题;
  • 修复了实例界面运行详情中修改pod数量后进行重新部署,pod能否增减判断错误的问题;
  • 修复了变更实例查询values接口参数的问题;
  • 修复了实例部署超时未发站内信的问题;
  • 修复agent不支持StatefulSet的问题;
  • 修复了修改域名时,端口下拉框中未显示出已有端口的问题;
  • 修复了RegistrySecret在Kubernetes中被删除后,而Choerodon未感知的问题;
  • 修复了集群重置后Pod数据未进行同步的问题;
  • 修复了Polaris扫描的超时机制在查询时不生效的问题;
  • 修复了创建集群的ChoerodonId可能为纯数字字符串的问题;
  • 对一个文件存在多个资源包含PV和PVC的情况做了处理;
  • 修复了集群管理页面,树结构中集群状态排序错乱的问题;
  • 修复了DevOps报表中代码提交图、构建次数图选择时间范围时,数据不准确的问题;
  • 修复了以运行结果为条件搜索部署记录时,未筛除批量部署的问题;

功能优化

  • “应用部署-资源”模块,实例视图与资源视图的环境层级,在环境名称后加上了所属的集群;

社区参与

感谢以下朋友在社区论坛中提出反馈和意见,在0.22版本更新中作出贡献,感谢大家一直以来的支持。

  • @PengtaoNing
  • @dongasai

更加详细的内容,请参阅Release Notes和官网用户手册。

安装文档: http://choerodon.io/zh/docs/installation-configuration/steps/

升级文档: http://choerodon.io/zh/docs/installation-configuration/update/0.21-to-0.22/

欢迎各位朋友通过Choerodon的GitHub和猪齿鱼社区进行反馈与贡献,帮助Choerodon猪齿鱼不断成长。Choerodon会持续优化,敬请期待。

-▼-

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:

欢迎加入Choerodon猪齿鱼社区,共同为企业数字化服务打造一个开放的生态平台。

· 7 分钟阅读

在首个 Sprint 开始之前,需要召开一个递增的 Sprint 计划。用来计划和确定一列敏捷发布火车的时间维度,通过定量的时间递增(Sprint)来保证编码实现和我们计划任务(Mission)的持续一致。PI 将在固定的时间箱内计划出一个可量化、可实现和最终可测量验收的计划路线图。Choerodon猪齿鱼通过以下步骤进行PI过程:

  • ART同步会议
  • 通过项目群看板促进可视化
  • 通过迭代日历提高敏捷团队可见性

ART同步会议

在 PI 计划会议之后,各种项目群事件创建了一个闭环系统,从而 “保持火车在轨道上行进”。如图所示: 

为了保持工作持续进展和透明度,就需要频繁的协作。为了评估和管理进度和依赖关系,ART通常通过各种同步会议进行协调。这其中包括:

  • Scrum of Scrum(SoS):发布火车工程师(RTE)每周(或更频繁)引导 Scrum of Scrum会议,来协调依赖,并将进展和障碍以可视化的方式呈现出来。Scrum Master或者其他人向大家同步敏捷团队实现里程碑和PI目标的进度,并管理团队间的依赖关系;
  • 产品负责人(PO)同步:产品经理(PM)和产品负责人(PO)通过 “PO 同 步”会议,对 ART 的进展在多大程度上与项目群 PI 目标相一致获得可视化呈现。讨论特性开发中遇到的问题或者创造的新机会,并评估任何可能出现的范围调整。这个会议也是每周进行一次,也可以根据实际情况更加频繁的举行。

一些 ART 将 Scrum of Scrums 会议和 PO 同步会议组合成一个“ART 同步”会议。ART同步会议有助于跟踪计划的进展并解决重要问题(障碍)。

ART同步会议需要展示:

  • 目标和特征的全部进展;
  • 需要上报给其他团队或计划级别的风险和问题;
  • 与其他团队的依存关系状;

通过ART同步会议,高级管理层和团队可以轻松了解进度,预测,依存关系和问题。这将有助于整个ART确实我们的目标是否对齐,是否存在障碍延缓按期交付。Choerodon通过项目群看板、迭代日历提供了较为全面的可视化依据。

通过项目群看板促进可视化

PI开启后,看板立即开启。项目群看板提供了流转可视化,通过特性在持续开发、持续集成、持续部署、持续交付中不断流动,最终实现价值流的交付。同时,看板有助于预测瓶颈,通过每个状态的队列长度,快速确定ART要面临的风险,并且及时消除风险。如下图所示:

通过迭代日历提高敏捷团队可见性

迭代日历完整、透明的展示了ART中各个敏捷团队的开发情况,项目群管理人员可以通过PI、团队、冲刺多个视角,再结合故事点、问题计数两种维度,多方位的展示各个团队、各个冲刺、各个工作项的进展情况。

总结

PI执行过程中,敏捷团队在源源不断的为ART提供动力,每个独立的敏捷团队在不断的进行迭代重复工作,这包括:迭代计划、每日站立会议、团队演示以及团队回顾。而ART管理人员只需要通过看板和迭代日历了解各个团队的进展,及时移除障碍。

如何在Choerodon中进行SAFe大规模敏捷实践,请参考大规模敏捷实践指南(一):如何开启大规模敏捷之旅。 了解SAFe的术语以及对应到Choerodon上的功能,请参考大规模敏捷实践指南(二):SAFe术语与Choerodon功能对照表。 了解什么是大规模敏捷框架SAFe以及Choerodon猪齿鱼如何聚焦SAFe框架理念进行大规模敏捷实践,请参考Choerodon大规模敏捷|大规模敏捷框架SAFe

关于猪齿鱼

Choerodon 猪齿鱼作为全场景效能平台,是基于Kubernetes,Istio,knative,Gitlab,Spring Cloud来实现本地和云端环境的集成,实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。

更加详细的内容,请参阅Release Notes官网

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:

欢迎加入Choerodon猪齿鱼社区,共同为企业数字化服务打造一个开放的生态平台。

· 18 分钟阅读

原文作者:Jeff Hale

原文地址:https://towardsdatascience.com/learn-enough-docker-to-be-useful-b0b44222eef5

翻译:付新圆

本篇文章是关于Dockerfiles的,这是Docker系列文章的第三部分。如果您还没有读过 第1部分,请先阅读它,您可以从全新的角度了解Docker容器概念。 第2部分是Docker生态系统的简要介绍。在以后的文章中,我将研究精简Docker映像、Docker CLI命令以及使用Docker的数据。      现在,让我们跳进这十几个Dockerfile说明中去吧!

图:跳进来

Docker映像

Docker容器是栩栩如生的Docker映像,它是一个独立的、最小的操作系统,带有应用程序代码。

Docker映像在构建时创建的,而Docker容器是在运行时创建。

Dockerfile是Docker的核心,Dockerfile告诉Docker如何构建用于制作容器的映像。

每个Docker映像都包含一个名为Dockerfile的文件,没有扩展名。调用Dockerfile docker build 创建映像时,假定该Dockerfile位于当前工作目录中,可以使用文件标志( -f )指定其他位置。

容器是由一系列层构建而成的,除位于最后一层之上的最终容器层外,每一层都是只读的。Dockerfile告诉Docker添加哪些层以及添加顺序。

每一层实际上只是一个文件,其中包含自上一层以来的更改。在Unix中,几乎所有内容都是文件。

基础图像提供了初始层,基本图像也称为父图像。

当图像从远程存储库拉到本地计算机时,只下载本地计算机上尚未存在的层。Docker就是通过重用现有层来节省空间和时间。

图:基本(跳跃)图像

Dockerfile指令是一行开头的大写单词,后跟其参数。Dockerfile中的每一行都可以包含一条指令。构建图像时,说明从上到下进行处理。说明如下:

FROM ubuntu:18.04 
COPY . /app

只有指令FROM,RUN,COPY和ADD才能在最终图像中创建图层,其他的指令可配置事物,添加元数据或告诉Docker在运行时执行某些操作,例如公开端口或运行命令。 在本文中,我假设您正在使用基于Unix的Docker映像。您也可以使用基于Windows的映像,但这是一个较慢,较不愉快,较不常见的过程。因此,如果可以,请使用Unix。

让我们快速浏览一下我们将探索的十二个Dockerfile指令吧。

Dockerfile指令

FROM —指定基本(父)图像。

LABEL —提供元数据,包括维护者信息。

ENV —设置持久性环境变量。

RUN —运行命令并创建图像层,用于将软件包安装到容器中。

COPY -将文件和目录复制到容器。

ADD -将文件和目录复制到容器,可以支持本地.tar文件。

CMD —为执行中的容器提供命令和参数,可以覆盖参数,只能有一个CMD。

WORKDIR —为以下说明设置工作目录。

ARG —定义在构建时传递给Docker的变量。

ENTRYPOINT —为执行中的容器提供命令和参数。争论依然存在。

EXPOSE —暴露端口。

VOLUME —创建目录安装点以访问和存储持久数据。

让我们开始吧!

说明和示例

Dockerfile可以像下面这样简单:

FROM ubuntu:18.04 

FROM

Dockerfile必须以FROM指令或ARG指令开头,后跟FROM指令。

FROM 关键字告诉Docker使用与提供的存储库和标签匹配的基础映像,基本图像也称为父图像。

在此示例中,ubuntu是映像存储库。Ubuntu是 官方Docker存储库的名称,该存储库提供了流行的Linux操作系统的Ubuntu版本的基本版本。

图:Linux吉祥物Tux

请注意,此Dockerfile包含基础映像的标记:18.04,这个标签告诉Docker在ubuntu仓库中镜像的哪个版本。如果不包含标签,则默认情况下,Docker将采用最新标签。为了使您的意图清晰明了,最好指定一个基本图像标签。

当上述Dockerfile首次用于在本地构建映像时,Docker下载ubuntu映像中指定的层。可以将这些层视为彼此堆叠。每一层都是一个文件,具有与前一层不同的一组文件。

创建容器时,可以在只读层的顶部添加可写层。

图:从 Docker文档

为了提高效率,Docker使用了一种写时拷贝策略。如果一个层存在于图像的前一层,而另一层需要对其进行读访问,Docker将使用现有文件。不需要下载任何内容。

当一个图像正在运行时,如果一个层需要被容器修改,那么该文件将被复制到顶部的可写层中。

更具实质性的Dockerfile

虽然我们的单线图很简洁,但它也很慢,提供的信息很少,并且在容器运行时什么也不做。让我们看一个较长的Dockerfile,它构建一个小得多的图像,并在容器运行时执行脚本。

FROM python:3.7.2-alpine3.8 
LABEL maintainer="[email protected]"
ENV ADMIN="jeff"
RUN apk update && apk upgrade && apk add bash
COPY . ./app
ADD https://raw.githubusercontent.com/discdiver/pachy-vid/master/sample_vids/vid1.mp4 \
/my_app_directory
RUN ["mkdir", "/a_directory"]
CMD ["python", "./my_script.py"]

这是怎么回事能?让我们逐步了解并揭开神秘面纱。 基本映像是带有标签3.7.2-alpine3.8的正式Python映像。从 源代码中可以看到,该映像包含Linux、Python和其他一些内容。高山图像之所以受欢迎,是因为它们体积小,速度快且安全。但是,Alpine映像并没有很多操作系统优点。如果需要,您必须自己安装这样的软件包。

LABEL

下一条指令是LABEL。LABEL将元数据添加到图像中。在本例中,它提供图像维护者的联系信息。 Labels不会减慢构建速度或占用空间,它们提供了有关Docker映像的有用信息,因此一定要使用它们。有关LABEL元数据的更多信息,请参见 此处

ENV

ENV设置在容器运行时可用的持久环境变量。在上面的例子中,您可以在创建Docker容器时使用ADMIN变量。

ENV非常适合设置常量,如果您在Dockerfile中的多个位置使用常量,并且想在以后更改其值,则可以在一个位置进行更改。

图:环境

对于Dockerfiles,通常可以通过多种方式完成同一件事。针对您的案例,最好的方法是平衡Docker约定、透明性和速度。例如,RUN、CMD和ENTRYPOINT具有不同的用途,并且均可用于执行命令。

RUN

RUN在构建时创建一个层。每次运行后,Docker都会提交映像的状态。

RUN通常用于将软件包安装到映像中 在上面的示例中, RUN apk update && apk upgrade 告诉Docker从基础映像更新软件包 && apk add bash 告诉Docker将bash安装到映像中。

apk代表Alpine Linux软件包管理器。如果您使用的是Alpine以外的其他版本的Linux基础映像,则应使用RUN apt-get而不是apk安装软件包。apt代表高级包工具。在后面的示例中,我将讨论安装包的其他方法。

图:跑

RUN及其同级命令CMD和ENTRYPOINT可以在exec表单或shell表单中使用。Exec form使用的JSON数组语法如下:

例如: RUN ["my_executable", "my_first_param1", "my_second_param2"]

在上面的示例中,我们使用格式为的shell形式 RUN apk update && apk upgrade && apk add bash

稍后在Dockerfile中,我们使用首选的exec形式 RUN ["mkdir", "/a_directory"] 创建目录。别忘了对exec form使用JSON语法的字符串使用双引号!

COPY

COPY . ./app 指令告诉Docker在本地构建上下文中获取文件和文件夹,并将它们添加到Docker映像的当前工作目录中。如果不存在,复制将创建目标目录。

图:复制

ADD

ADD与COPY执行相同的操作,但有两个以上的用例。ADD可用于将文件从远程URL移动到容器,ADD可以提取本地TAR文件。

我在上面的示例中使用ADD将文件从远程URL复制到容器的 my_app_directory中 。Docker文档不建议以这种方式使用远程URL,因为您无法删除这些文件。额外的文件会增加最终图像的大小。

Docker文档还建议尽可能使用COPY而不是ADD来提高清晰度。Docker没有将ADD和COPY合并到一个命令中,以减少Dockerfile指令的数量来保持直线,这太糟糕了。

注意,ADD指令包含 \ 换行符,使用它可以通过将一条长指令拆分成几行来提高可读性。

CMD

CMD向Docker提供了一个在容器启动时运行的命令。它不会在构建时将命令的结果提交给映像。在上面的示例中,CMD将使Docker容器在运行时运行my_ script.py 文件。

图:那是CMD!

有关CMD的其他几件事:

  • 每个Dockerfile仅一个CMD指令。否则,除最后一个以外的所有内容都将被忽略。
  • CMD可以包含一个可执行文件。如果存在没有可执行文件的CMD,则必须存在ENTRYPOINT指令。在这种情况下,CMD和ENTRYPOINT指令都应为JSON格式。
  • 命令行参数将 docker run 覆盖Dockerfile中提供给CMD的参数。

准备好了吗?

让我们在另一个Dockerfile示例中介绍更多说明。

FROM python:3.7.2-alpine3.8 
LABEL maintainer="[email protected]"
# Install dependencies
RUN apk add --update git
# Set current working directory
WORKDIR /usr/src/my_app_directory
# Copy code from your local context to the image working directory
COPY . .
# Set default value for a variable
ARG my_var=my_default_value
# Set code to run at container run time
ENTRYPOINT ["python", "./app/my_script.py", "my_var"]
# Expose our port to the world
EXPOSE 8000
# Create a volume for data storage
VOLUME /my_volume

请注意,您可以在Dockerfiles中使用注释。注释以 # 开头。 软件包安装是Dockerfiles的主要工作。如前所述,有几种方法可以使用RUN安装软件包。

您可以使用apk在Alpine Docker映像中安装软件包,apk就像常规Linux构建中的apt-get。例如,带有基本Ubuntu映像的Dockerfile中的软件包可以像这样更新和安装: RUN apt-get update && apt-get install my_package

除了apk和apt-get 之外 ,还可以通过pip,wheel和conda安装Python软件包。其他语言可以使用各种安装程序。

基础层需要向安装层提供相关的软件包管理器。如果您在安装软件包时遇到问题,请在安装软件包管理器之前尝试使用它们。

您可以将RUN与pip一起使用,并在Dockerfile中直接列出要安装的软件包。如果这样做,则将您的软件包安装到一条指令中,并用换行符(\)将其分开。与多个RUN指令相比,此方法提供了清晰度和更少的层数。

或者,您可以在文件中列出软件包要求,然后在该文件上运行软件包管理器。人们通常将文件命名为 requirements.txt 。我将在下一篇文章中分享一个推荐的模式,以利用build.ca缓存与 requirements.txt 一起使用。

WORKDIR

WORKDIR会更改容器中的工作目录,以供后面的COPY、ADD、RUN、CMD和ENTRYPOINT指令使用。几点注意事项:

  • 最好使用WORKDIR设置绝对路径,而不是使用Dockerfile中的 cd 命令在文件系统中导航。
  • 如果该目录不存在,则WORKDIR会自动创建该目录。
  • 您可以使用多个WORKDIR指令。如果提供了相对路径,则每个WORKDIR指令都会更改当前工作目录。

图:某种工作目录

ARG

ARG定义了一个在构建时从命令行传递到映像的变量。可以在Dockerfile中为ARG提供默认值,如示例所示: ARG my_var=my_default_value

与ENV变量不同,ARG变量不适用于运行中的容器。但是,在生成映像时,可以使用ARG值在命令行中为ENV变量设置默认值。然后,ENV变量在容器运行期间一直存在。

ENTRYPOINT

ENTRYPOINT指令还允许您在容器启动时提供默认命令和参数。它看起来与CMD相似,但是如果使用命令行参数运行容器,则ENTRYPOINT参数不会被覆盖。

而是将传递给的命令行参数 docker run my_image_name 附加到ENTRYPOINT指令的参数中。例如, docker run my_image bash 将参数 bash 添加到ENTRYPOINT指令的现有参数的末尾。

图:进入某处

Dockerfile应该至少具有一个CMD或ENTRYPOINT指令。

Docker文档中有一些关于在CMD和ENTRYPOINT之间选择初始容器命令的建议:

  • 当您 需要每次运行 相 同 的 命令时,请 选择 ENTRYPOINT。
  • 当 容器 将 用作可执行程序时, 首选入口点 。
  • 当您 需要提供 额外的默认参数, 可以从命令行 重写 时, 使用 CMD。

在上面的示例中, ENTRYPOINT ["python", "my_script.py", "my_var"] 让容器在容器开始运行时运行带有参数 my_var 的python脚本 my_script.py 。 然后, my_script可以 通过argparse使用 my_var 。请注意, my_var 具有ARG先前在Dockerfile中提供的默认值。因此,如果未从命令行传递参数,则将使用默认参数。

Docker建议您通常使用ENTRYPOINT:的exec形式 ENTRYPOINT ["executable", "param1", "param2"] 。这种形式是使用JSON数组语法的形式。

EXPOSE

EXPOSE指令显示要发布哪个端口以提供对正在运行的容器的访问。EXPOSE实际上不会发布端口。相反,它充当构建映像的人员与运行容器的人员之间的文档。

图:暴露

docker run-p 标志一起使用,以在运行时发布和映射一个或多个端口。大写 -P 标志将发布所有公开的端口。

VOLUME

VOLUME指定您的容器将在哪里存储和/或访问持久数据。

图:卷

总结

Dockerfile也许是Docker掌握的关键组件。我希望本文能帮助到你们。

· 15 分钟阅读

原文作者:Sjoerd Nijland

原文地址:https://medium.com/serious-scrum/the-sprint-planning-c24df3e09779

翻译:柴晓燕&付新圆

对于敏捷中的活动有很多,本文先从Sprint计划开始,分享一些方法、建议和注意事项,这些对理解和实践Scrum都很有帮助。

Who?

Sprint计划的参与者:整个Scrum团队。

请注意,Sprint计划是一个积极的、合作的活动。如果需要的话,大家可以随意走动查找资料或解决问题。开发团队可以召集其他人来帮忙,在会议期间能收集到更多信息。

“开发团队还可以邀请其他人参加,以提供技术或领域建议。” — Scrum指南

参与性

并不是每位成员都会在参与活动时表现出积极主动和创造性,有些成员只有在感到自信或舒服时才会加入。

出勤率和参与度低都会降低透明度,并带来风险。Scrum Master认为每个人都参加和参与是他们的责任。

“ Scrum Master可以确保活动进行,并确保参与者了解其目的。” — Scrum指南

我认为,解释出勤和参与的价值,同时创造一个舒适、愉快、平静和尊重的环境,是Scrum Master 激励团队成员参与的最佳方法。

“给他们提供所需的环境和支持,并信任他们来完成工作。” —敏捷宣言。

有时,参与者可能会占据主导地位,并试图利用一事件来指导和影响团队的方向。这些输入可能非常有价值,但可能会妨碍其他人添加宝贵的输入,参与者应该意识到这一点。当团队成员之间发生不尊重甚至敌对时,Scrum Master应该及时介入。团队要把Scrum Master视为教练,以保护团队环境的安全。

When?

Sprint计划发生在什么时候: Sprint的开始。

这其实是一个很难回答的问题,《Scrum指南》并没有明确指出Sprint计划必须在一开始就进行。 事实上,如果准确地解释的话,在Sprint计划期间计划的工作指的是即将到来的Sprint,而不是当前的或这个Sprint。 Sprint计划不会在两者之间进行,因为Sprint在上一个Sprint结束后立即开始。请记住,Sprint充当的是事件的容器。

《Scrum指南》暗示了这一点。

“每个人都在另一个Sprint中重新组合,计划开始另一个Sprint” —《 Scrum指南》。

幸运的是,Scrum.org的Scrum词汇表更加具体:

“Sprint计划:定时活动,以开始Sprint。” — Scrum词汇表

团队在优化期间准备Sprint计划并不少见。总的来说,Sprint计划在一致的时间和地方开始。

How long ?

如果进行长度为一个月的冲刺,最多需要8个小时来进行冲刺计划 。对于周期短的冲刺, 则花费的时间更少。

团队通常会根据sprint的周期来制定迭代计划 ,一个星期的Sprint可能 需要2个小时的计划时间。请记住,这只是最大时间,没有最小时间。经验丰富的团队很可能在时限到期之前完成计划 。

好的协作与改进能促使sprint计划会议更加迅速,更加有效。就是说,时间并不能决定解决问题的效率 。

准备

Sprint计划时我们要准备以下内容 :

  • 来自Sprint回顾会的反馈和有价值的输入内容 (可能已经加入到产品待办事项列表中)
  • 完善的产品待办列表
  • 在上次迭代回顾会议上确定的至少一项 优先级较高的流程改进
  • 讨论Sprint的潜在目标
  • “完成”的标准,即验收标准。
  • 最近一次的产品增量
  • 最近一次迭代开发团队的表现
  • 冲刺期间开发团队的预计容量

在我的项目中,团队经历了很多次迭代 ,成员们都在呼吁推迟Sprint计划,他们要么不认为上一个Sprint已经完成,要么觉得自己准备不充分 。

那么, 上一个Sprint中 未被认 为“完成”的工作可以重新 规划 到下一个Sprint中。 请记住一个冲刺规定的时间范围结束标志着这个冲刺的结束,当然取消冲刺除外。

无论哪种情况,Sprint计划都不会推迟。如果在Sprint计划之前,上述所有内容都不是透明的,那么Sprint计划的时间范围可能允许在计划期间创造这种透明性。

Ready的解释

一些团队使用“ Ready ”的定义。Scrum仅规定了一个定义(尽管这并不排除团队引入诸如 INVEST标准之类的其他定义):

“可以由开发团队在一个Sprint内“完成”的产品Backlog项被认为是“准备好”的,可以在Sprint计划中进行选择。”—Scrum指南。

目的

“在Sprint计划结束时,开发团队应该能够向产品负责人和Scrum Master解释其打算如何作为自组织团队来实现Sprint目标并创建预期的增量。” — Scrum指南

并且 :

“ 开发团队在Sprint 的第一天 计划的工作将在本次会议结束前被分解。” — Scrum指南(强调)

如果实现了此目的,就达到了Sprint计划的目的 。

为了实现此目的,Sprint计划分为两个部分:

1.此Sprint可以做什么?

Scrum团队共同的 Sprint目标 应该达成一致。 产品负责人不指定Sprint目标,而是讨论Sprint应该实现的目标。最开始的时候团队需要透明性, 每个人对Sprint的目的的理解都需要保持一致。Sprint目标为开发团队选择实施的目标提供了一定程度的灵活性。冲刺目标可能雄心勃勃(毕竟这是一个目标),并有促进集体协作的作用。

产品负责人也将讨论产品待办事项,如果这些事项在Sprint中完成,将达到Sprint目标。

然后,开发团队将创建一个 Forecast (预测) ,这是对产品待办事项的初步选择,基于对产品的认识可以在Sprint中完成任务以达到Sprint目标。

“只有开发团队才能评估在即将到来的Sprint中可以完成的工作。” — Scrum指南

开发团队可以要求产品负责人说明并重新协商这些待办事项 。

在第一个Sprint的末尾,开发团队应该了解为什么要构建增量。

2.所选工作将如何完成?

当协调一致时,开发团队将制定一个交付的初始计划。 这些内容就是Sprint Backlog,它将在整个Sprint中继续出现。请记住,这还包括来自 最近一次 Sprint回顾 会 的改进计划。

温馨提示:预测并非承诺。开发团队创建的预测,应有效的去实施或对有价值的更改进行实践。 虽然开发团队作为专业人员承诺尽其所能, 但质量目标不应降低, 团队也不应为了实现预测而在“完成”的定义上偷工减料。

在此活动中,开发团队可能已经自组织并承担了工作:

“开发团队在Sprint计划期间以及整个Sprint中根据需要自行组织以进行Sprint Backlog中的工作。” — Scrum指南

透明性

除了为Sprint计划准备输入之外, 团队还有很多方法来完成Sprint计划。在Sprint计划期间,团队的力量在工作中的汇报是显而易见的。

团队来决定如何最好地推动Sprint计划,是非常关键的。

“流程中最重要的是必须对负责结果的人员 可见 。” — Scrum指南

并且 :

“产品负责人的决定在产品待办事项列表的内容和 序列中 可见 。” — Scrum指南

更重要的是:

“ Sprint待办事项是开发团队计划在Sprint期间完成的工作的 高度可见的 实时 影像 ” —《 Scrum指南》

也就是说,我要提醒大家不要仅仅依赖电子看板来实现这种透明性:

有些糟糕的设置,例如:“ 团队会不耐烦地、漫不经心地围坐在一张桌子旁,桌子上的大屏幕正显示着电子看板,团队们 紧盯 着一个人按照指示更新看板…”

S.W.O.T

团队可以考虑的非Scrum技术是一个SWOT画布,在这个画布上,团队可以使重要因素变得透明。依赖关系会带来风险,因此可以在sprint期间跟踪它们。

当然,在Sprint过程中,也会发现或引入新的威胁,如障碍物。Sprint计划可以帮助团队为当时已知的事情做准备,也需要考虑到它未来可能遇到的未知挑战。

分歧

一致性,是我认为的任何Scrum活动的目的(即使Scrum指南中没有使用这个术语),仔细的检查能使团队在实际情况上保持一致,从而形成共同的理解。

通常,在Sprint计划期间会讨论许多主题,如果不是所有成员都在场,或者输入内容不透明,那么团队可能就会做出错误的假设,沟通不畅,从而导致团队不协调。产生了分歧将无法做出最佳决策,从而引入风险且价值无法最大化。

有时候,Scrum团队成员很难真正地在Sprint目标、预测或如何进行工作的计划上保持一致。与任何事件一样,每个人都必须遵守Scrum价值观,每个人都应该能够以尊重的方式表达自己的想法,不同的观点是学习的机会。当团队不能就如何同意或不同意达成一致时,这将在整个开发过程中造成严重的中断。

自组织团队需要学会平和的处理分歧。“不同意但承诺”是团队可以同意的潜在原则,但这可能并不适合每个团队。因此,有多种方法可以达成共识。为了快速检测是否达成共识,团队可以采用诸如 使用手势这样的方式。

请记住,仅在Sprint的第一天就计划好工作就足够了。

Scrum Master对 Sprint计划的作用

作为Scrum Master,可以试着验证团队中每个人是否理解Sprint的目的和方法,并且支持Sprint。

整个团队是否了解如何协作?信心水平是多少?他们实际上是在承诺还是在默默地服从?

从Sprint计划结束时的氛围来看,Scrum Master通常已经可以在某种程度上预测整个Sprint的期望。

请记住,这仅仅是开始。随着Sprint的进步和更多的知识,计划必须进行调整,并且团队的自我组织,实现Sprint目标或创造预期增量的能力可能会受到挑战。

另外,作为Scrum Master,提醒Scrum团队他们的改进目标很重要,在制定计划时也要考虑到这一点。

Sprint计划在其时间范围到期时结束,或者如果事件的目的实现了,则可以提前结束。

· 8 分钟阅读

原文作者:Jeff Hale

原文地址:https://towardsdatascience.com/learn-enough-docker-to-be-useful-1c40ea269fa8

翻译:付新圆

在本系列的第1部分《Docker-第1部分:什么是Docker?》我们探讨了Docker容器的概念以及Docker容器的重要性,文章的最后我们把Docker类比成了一个披萨,并把它拆解开来解释Docker容器的结构和用途。在本文中,将分享Docker生态系统中的常用的术语。

遵循本系列第一篇文章中的食品主题,这里我们将甜甜圈想象成一个Docker容器。

Docker生态系统术语

为了方便大家理解,我将Docker术语分为两类:基础术语和进阶术语。

Docker 基础术语

1.Docker平台

Docker平台是 Docker的软件,可在任何Linux服务器上的容器中打包和运行应用程序。Docker平台捆绑了代码文件和依赖项,支持可移动性和可重复性来促进平台扩展。

2.Docker引擎

Docker引擎是客户端服务器应用程序。Docker公司将Docker引擎分为两种产品。

图:引擎让事情运转

3.Docker客户端

Docker客户端是许多Docker用户与Docker交互的主要方式。使用 Docker命令行界面(CLI)时,请在终端中输入以docker开头的命令,然后Docker客户端使用Docker API将命令发送到Docker Daemon。

图:Docker文档中的图表

4.Docker Daemo

Docker Daemo是侦听Docker API请求的Docker服务器,管理映像、容器、网络和卷。

5.Docker卷

Docker卷是存储应用程序消耗和创建的持久数据的最佳方式。在本系列的第5部分中,我们将对Docker卷进行更多的讨论。

图:卷

6.Docker 注册表

Docker注册表是存储Docker映像的远程位置,将图像推送到注册表并从注册表中提取图像,可以托管注册表或使用提供程序的注册表。例如,AWS和googlecloud都有注册。

7.Docker Hub

Docker Hub是Docker映像的最大注册表,也是默认注册表。您可以在Docker Hub上免费查找图片并存储图片。

图:轮毂和辐条

8.Docker 存储库

Docker 存储库是具有相同名称和不同标签的Docker图像的集合,该标签是图像标识符。

通常,一个存储库具有同一映像的不同版本。例如,Python 是Docker Hub上最流行的官方Docker映像存储库的名称。Python:3.7-slim 指的是Python存储库中带有3.7-slim标签的图像版本。您可以将存储库或单个映像推送到注册表。

Docker 进阶术语

接下来我们看一下与扩展多个Docker容器有关的Docker术语,以下四个概念涉及一次使用多个容器。

1.网络容器

网络容器可以将Docker容器连接在一起,连接的Docker容器可以位于同一主机或多个主机上。有关Docker网络的更多信息,请参阅这篇文章

图:Docker网络

2.Docker Compose 

Docker Compose是一种工具,可让您更轻松地运行需要多个Docker容器的应用程序。Docker Compose允许您将命令移动到docker-compose.yml文件中以供重用。Docker Compose命令行界面(cli)使与多容器应用程序的交互变得更加容易。Docker Compose随您的Docker安装一起免费提供。

3.Docker Swarm

Docker Swarm是用于协调容器部署的产品。Docker官方教程的第四部分介绍了Docker Swarm。

图:蜂群

4.Docker 服务

Docker服务是分布式应用程序的不同部分。

服务实际上只是“生产中的容器”。一个服务仅运行一个映像,但它规定了映像的运行方式—应该使用什么端口,应该运行多少个容器副本,这样服务就有了它需要的容量,等等。扩展服务会更改运行该软件的容器实例的数量,从而在流程中为服务分配更多的计算资源。

Docker服务允许您跨多个Docker Daemon扩展容器,并使Docker Swarms成为可能。

回顾

以下用一行文字总结以帮助你理清这十几个术语。

基本

  • 平台—使Docker容器成为可能的软件
  • 引擎—客户端服务器应用程序(CE或Enterprise)
  • 客户端—处理Docker CLI,以便您可以与守护程序进行通信
  • Daemon—Docker服务器,管理关键内容
  • 卷—持久数据存储
  • 注册表—远程映像存储
  • Docker Hub—默认和最大的Docker 注册表
  • 存储库—Docker图像的集合,例如Alpine

缩放比例

  • 网络—将容器连接在一起
  • 撰写—节省多容器应用程式的时间
  • Swarm—协调容器部署
  • 服务—生产中的集装箱

因为我们遵循食物的隐喻,所以我们为引入了另一个相关术语:Kubernetes。

图:再加一层甜甜圈并洒上糖果

Kubernetes自动执行容器化应用程序的部署、扩展和管理。它是容器编排市场的赢家,代替Docker Swarm,使用Kubernetes来扩展具有多个Docker容器的项目。Kubernetes不是Docker的官方部分,它更像是Docker的BFF。

图:Kubernetes

现在您已经了解了Docker的概念和常用术语,那么我建议您尝试使用Docker。

使用Docker

Docker在Linux、Mac和Windows上本地运行。如果您使用的是Mac或Windows计算机,请在此处安装最新稳定版本的Docker Desktop 。作为奖励,它附带Kubernetes。如果要在其他地方安装Docker,请转到此处查找所需的版本。

安装Docker之后,执行Docker教程的前两部分。

总结

以上就是关于Docker的十二个术语的相关内容。在本系列的下三个部分中,我们将深入研究Dockerfile指令,请持续关注我们。

· 8 分钟阅读

当有多个开发人员参与项目时,通过Git进行分支和Tag管理,将软件的版本控制以及分支管理贯穿于整个软件产品的生命周期,能有效的避免代码冲突,提高开发效率。Choerodon 代码仓库就是基于 Git 进行代码版本管理。本文介绍了 Choerodon 猪齿鱼中开发应用服务的方法,包括创建分支、克隆、推拉代码、合并分支等。

开发应用服务

在Choerodon中开发应用服务之前,首先需确认已在Choerodon项目下创建应用服务,并配置了 Git,包括下载安装、设置等。

第一步:创建分支

Choerodon使用 GitLab 进行分支管理,默认分支为 master。目前支持六种常见的分支类型:

  1. master:主分支,用于版本持续发布;
  2. feature:特性分支,用于日常开发时切出分支进行单功能开发;
  3. bugfix:故障修补分支,通常用于修复故障;
  4. release:发布分支,适用于产品发布、产品迭代;
  5. hotfix:热修分支,用于产品发布后修复缺陷;
  6. custom:自定义分支,用户可以自定义需要的分支类型。

    注:bugfix旨在与敏捷的问题类型(故障)呼应,用于标识此分支的任务是修复某个故障

这里我们以 Feature 分支为例,在Choerodon中进行分支创建。

  1. 在 代码管理 -> 分支 界面,选择应用服务猪齿鱼Todo服务

  2. 点击创建分支,如果没有issue可选择,则先创建问题, 选择对应的issue;

  3. 分支来源选择master,填写issue号,如feature-1,点击创建,即可创建一个分支;

    例如,

    • 问题名称: choerodon-dev-1 猪齿鱼快速入门文档
    • 分支来源: master
    • 分支类型: feature
    • 分支名称: feature-choerodon-dev-1

  4. 创建完分支之后,您就可以进行后续的本地开发。

Choerodon 采用 githubflow作为我们的分支管理策略的主体。并在此基础上,参考了一些其他策略,对开发者的开发分支做了一定程度上的细分。更多相关信息参考分支管理

第二步:拉取代码仓库

  1. 代码仓库 菜单,找到猪齿鱼Todo服务的仓库地址,复制仓库地址;
  2. 本地通过git 命令拉取生成的项目代码;
  3. 切换到对应分支进行本地开发。

$ git clone `仓库地址`
$ cd ./choerodon-todo-servie
$ git checkout feature-choerodon-dev-1

克隆代码时候,会让输入用户名,密码。用户名为平台用户名,密码为用户新建后收到的站内信中的Gitlab仓库密码,若忘记密码,可以到个人信息页面重置GitLab仓库密码。

第三步:本地开发

将代码克隆到本地后,就可以在本地进行开发。

通过Choerodon 提供的MicroService 应用服务模板,会生成一个极简单的spring boot 应用服务。模板本身生成的应用服务可以直接运行在平台上,如需拓展更多功能,可具体参考后端开发手册

第四步:提交代码

当本地做了相关修改之后,需要将本地仓库的代码提交到远程分支上。提交的用户名密码同克隆代码库的一样。

$ git add .
$ git commit -m "[ADD] init todo-service"
$ git push origin feature-choerodon-dev-1

提交时需要遵循Choerodon 的规范:

  • [IMP] 提升改善正在开发或者已经实现的功能
  • [FIX] 修正BUG
  • [REF] 重构一个功能,对功能重写
  • [ADD] 添加实现新功能
  • [REM] 删除不需要的文件

第五步:代码集成

当代码提交到服务器之后,可以在页面查看持续集成。

  1. 在代码管理 -> 持续集成 页面,选择应用服务猪齿鱼Todo服务
  2. 点击阶段跳转到Gitlab 查看 CI 执行情况。

第六步:合并分支

当 CI 执行通过以后,可以将feature分支合并到master分支上。

  1. 在代码管理 -> 合并请求 页面,选择应用服务猪齿鱼Todo服务
  2. 点击创建合并请求,跳转到Gitlab;
  3. 分别选择源分支为feature-choerodon-dev-1 ,目标分支为master,并提交合并请求。等待ci流水线通过后,点击合并分支。

master分支的ci流水线 通过以后,在应用服务 -> 点击应用服务 猪齿鱼Todo服务 ,便能在”服务版本“Tab页中看到猪齿鱼Todo服务 生成的版本。此处的版本会用于后续的部署操作。若想了解更多Choerodon猪齿鱼版本相关的内容,可参考《Choerodon猪齿鱼实践之持续交付中的分支管理与版本控制》。

总结

以上就是使用Choerodon开发应用服务的全部流程,应用服务的开发过程也可以说是代码管理的过程,支持着团队的协作开发与持续集成,保证项目的进度和效率。

关于猪齿鱼

Choerodon 猪齿鱼作为全场景效能平台,是基于Kubernetes,Istio,knative,Gitlab,Spring Cloud来实现本地和云端环境的集成,实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。

更加详细的内容,请参阅Release Notes官网

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:

欢迎加入Choerodon猪齿鱼社区,共同为企业数字化服务打造一个开放的生态平台。