RC3使用的是鲲鹏916的CPU，RC6使用的是鲲鹏920的CPU，功能更为强大。前期解放云盘测试时使用的是RC3规格的机器，RC3规格的机器很快就要停用了，后面统一使用RC6。因此需要将软件从RC3切换到RC6。本文提供从RC3到RC6的迁移指导，可供相关人士参考。整体切换步骤：1、 导出被迁移主机的列表信息2、 确认主机名称和IP地址的映射关系（特别是在操作系统里面修改过主机名称的操作）3、 关闭云主机4、 做整机镜像（多台云主机可并行）5、 解绑EIP，删除云主机（包含数据盘）6、 基于整机镜像拉起RC6实例（保持主机名和私网IP地址不变）7、 绑定EIP8、 验证环境 一、导出被迁移主机的列表信息选中需要导出的云主机，点击如下图标红的图标导出云主机信息。二、确认主机名称和IP地址的映射关系明确下是否在操作系统里面修改过主机名称的操作，如果有，建议修改上一步的列表信息，将修改后的主机名称填充进去。三、关闭云主机正常关闭云主机。四、做整机镜像1、 在做整机镜像前，需要提前根据迁移云硬盘的容量购买备份存储库2、 在关闭的云主机的“更多”选择“创建镜像”，创建镜像名称的时候，选择整机镜像，镜像名称建议跟主机名称保持一致，便于后续的RC6云主机发放。创建镜像速度跟云主机磁盘使用的大小有关系。                        五、解绑EIP，删除云主机选中对应的EIP，进到EIP界面，选择“解绑”。按正常删除操作，删除云主机，勾选上云服务器挂载的数据盘六、用整机镜像拉起RC6实例在镜像管理界面，选中已经做好的整机镜像，点击“申请服务器”按钮。新实例保持云主机、私网IP地址所在的子网及IP地址不变。  七、绑定EIP绑定原来的EIP。八、验证环境按照正常的业务逻辑验证环境。 

#化鲲为鹏，我有话说#有幸参加了鲲鹏云的公测，安装的系统是ubuntu，在使用过程中，发现使用 ubuntu 官方源的速度很慢。建议华为鲲鹏云官方应该提供华为内网的linux 软件源的镜像，与ubuntu centos 等官方的arm linux 软件源同步才可以，这样投入相对小，但是对于用户体验有非常大的帮助。根据测试 默认情况下apt-get 安装软件速度只有几kbvi /etc/apt/sources.list修改软件源为清华大学的源以后apt-get update速度有了很大提升Fetched 28.4 MB in 4s (6,890 kB/s)  

#化鲲为鹏，我有话说#用户可以通过已安装Windows或Linux操作系统的云服务器来创建私有镜像具体步骤Token认证，具体操作请参考Token认证。发送“POST https://IMS的Endpoint/v2/cloudimages/action”。在Request Header中增加“X-Auth-Token”。在Request Body中传入参数如下：{    "name":      "ims_test", //镜像名称（必填String）         "description": "云服务器制作镜像",      //镜像描述（非必填String）         "instance_id":      "877a2cda-ba63-4e1e-b95f-e67e48b6129a",//云服务器ID（必填String）         "tags":[                   "aaa.111",                   "bbb.333",                   "ccc.444"          ] //镜像标签列表（非必填List<String>）}请求相应成功后，返回job_id。查询job详情返回状态status为“SUCCESS”，则表示私有镜像创建成功 关于这个云服务器创建镜像的问题，想提个建议，能不能把这个过程稍简化一些，如果有批量的云服务器ECS，如何可以快速处理这项工作？

RT

opensuse 镜像好几天没更新了，日期一直停在8月14日

能否能提供个同步状态页面，镜像页面的时间不准确如 http://mirrors.ustc.edu.cn/status/和https://mirrors.tuna.tsinghua.edu.cn/status/#syncing-status这样。

E: Release file for https://mirrors.huaweicloud.com/debian/dists/buster-updates/InRelease is expired (invalid since 2d 0h 26min 0s). Updates for this repository will not be applied.E: Release file for https://mirrors.huaweicloud.com/debian/dists/buster-backports/InRelease is expired (invalid since 2d 0h 26min 1s). Updates for this repository will not be applied.

镜像名称：aosp镜像简介：Android 开放源代码项目镜像源同步方案：TUNA:https://mirrors.tuna.tsinghua.edu.cn/help/AOSP/USTA:https://lug.ustc.edu.cn/wiki/mirrors/help/aosp/

如果可以的话 希望可以更新最新版本

华为开源镜像站上只有centos最新版本7.6和6.10的下载链接，但有时需要使用旧版本，能否增加7.3-7.5和6.9版本的下载链接（x86_64 & aarch64）。

   目前，全世界90%以上的智能手机、穿戴设备、智能电视、智能驾驶等都基于ARM架构，全球一共有千亿级基于ARM架构的芯片在运行，可以说ARM已经是全球最大的计算生态系统。而随着今年1月，华为宣布推出业界最高性能ARM-based处理器-鲲鹏920（Kunpeng 920），以及基于鲲鹏920的TaiShan服务器。基于ARM的数据中心及云服务也将越来越受欢迎。      对开发者来说，ARM开放的指令集和丰富的端侧生态让开发者有更多更好的积木可搭，快速打造出更多的创新产品。同时，基于ARM的云服务架构，能更好的支撑智能终端、边缘和云的协同，从而实现高效开发、性能最优和一致的体验。     可以明显感觉到的是，近期询问支持ARM架构操作系统源的用户也多了起来，为此，特地整理了华为开源镜像站支持ARM架构的系统镜像源，欢迎体验：AlpineAlpine   Linux 是一个社区开发的面向安全应用的轻量级Linux发行版。适合用来做Docker镜像、路由器、防火墙、VPNs、VoIP 盒子   以及服务器的操作系统，基于 uClibc 和 Busybox。支持架构：aarch64，armhf，x86，x86_64Alpine的镜像地址为：https://mirrors.huaweicloud.com/alpine/ CentOS-AltarchCentOS（Community   Enterprise Operating System，中文意思是社区企业操作系统）是Linux发行版之一，它是来自于Red Hat Enterprise   Linux依照开放源代码规定释出的源代码所编译而成。由于出自同样的源代码，因此有些要求高度稳定性的服务器以CentOS替代商业版的Red Hat   Enterprise Linux使用。两者的不同，在于CentOS完全开源。支持架构：aarch64，armhfp，i386，power9，ppc64CentOS-Altarch镜像地址：https://mirrors.huaweicloud.com/centos-altarch/ DebianDebian   GNU/Linux，简称Debian，一款Linux发行版，是为数极少的纯社区驱动的Linux发行版，而不是由商业公司或者政府机构所掌控。     由于 Debian 采用了 Linux Kernel （操作系统的核心），但是大部分基础的操作系统工具都来自于 GNU 工程， 因此又称为   Debian GNU/Linux。Debian GNU/Linux 附带了超过 43000   个软件包，这些预先编译好的软件被打包成deb格式，以便于安装、卸载和升级。包管理系统名为dpkg（底层），前端工具有apt、aptitude和图形界面管理工具等。Debian的包管理系统是其最出色的特性，深受其用户的喜爱和赞赏。支持架构：AMD64   (x86_64), Intel x86, ARM, MIPS, ppc64el, s390x 等Debian的仓库地址为：https://mirrors.huaweicloud.com/debian/Debian-Security的镜像地址为：https://mirrors.huaweicloud.com/debian-security/Debian的镜像地址为：https://mirrors.huaweicloud.com/debian-cd/ EPELEPEL   (Extra Packages for Enterprise Linux) 是由 Fedora 社区(Fedora Special Interest   Group) 为企业 Linux 创建、维护和管理的一个高质量附加包集合，适用于但不仅限于 Red Hat Enterprise Linux   (RHEL), CentOS, Scientific Linux (SL), Oracle Linux (OL)等版本,装上了   EPEL之后，就相当于添加了一个第三方源。支持架构：aarch64,ppc64,ppc64le,x86_64EPEL的仓库地址为：https://mirrors.huaweicloud.com/epel/ EulerEulerOS是具备高安全性、高可扩展性、高性能、开放的企业级Linux操作系统平台，能够满足客户从传统IT基础设施到云计算服务的各种需求。EulerOS对ARM64架构提供全栈支持，打造完善的从芯片到应用的一体化生态系统。支持架构：x86_64，aarch64Euler的镜像地址为：https://mirrors.huaweicloud.com/euler/ FedoraFedora   是一款基于 Linux 的操作系统，也是一组维持计算机正常运行的软件集合。Fedora 由Fedora   Project社区开发、红帽公司赞助，目标是创建一套新颖、多功能并且自由和开源的操作系统。    Fedora基于Red Hat Linux，在Red Hat Linux终止发行后，红帽公司计划以Fedora来取代Red Hat   Linux在个人领域的应用，而另外发行的Red Hat Enterprise Linux（Red Hat企业版Linux，RHEL）则取代Red Hat   Linux在商业应用的领域。支持架构：aarch64，x86_64Fedora的镜像及仓库地址为：https://mirrors.huaweicloud.com/fedora/KaliKali   Linux是基于Debian的Linux发行版， 设计用于数字取证操作系统。由Offensive Security   Ltd维护和资助。最先由Offensive Security的Mati Aharoni和Devon   Kearns通过重写BackTrack来完成，BackTrack是他们之前写的用于取证的Linux发行版 。Kali Linux预装了许多渗透测试软件，包括nmap 、Wireshark 、John the Ripper，以及Aircrack-ng.[2]   用户可通过硬盘、live CD或live USB运行Kali Linux。Kali Linux既有32位和64位的镜像。可用于x86   指令集。同时还有基于ARM架构的镜像，可用于树莓派和三星的ARM Chromebook支持架构：amd64,   armel, armhf, i386Kali的仓库地址为：https://mirrors.huaweicloud.com/kali/Kali的镜像地址为：https://mirrors.huaweicloud.com/kali-images/ Ubuntu-PortsUbuntu（友帮拓、优般图、乌班图）是一个以桌面应用为主的开源GNU/Linux操作系统，Ubuntu   是基于Debian GNU/Linux，支持x86、amd64（即x64）和ppc架构，由全球化的专业开发团队（Canonical Ltd）打造的支持架构：arm64,armhf,powerpc,ppc64el,s390xUbuntu-Ports的仓库地址为：https://mirrors.huaweicloud.com/ubuntu-ports/ 更多详情请访问华为开源镜像站： https://mirrors.huaweicloud.com/如果您对镜像站如何更好的支持ARM生态有好的想法或建议，欢迎留言交流。

镜像名称yarnhttps://yarnpkg.com/镜像简介它是NodeJS的包管理器，是npm的一个替代品。镜像源地址/同步方案镜像是普通系统源的类型。参考：https://yarnpkg.com/en/docs/install#debian-stable参考安装方式：curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add - echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list sudo apt-get update && sudo apt-get install yarn

镜像名称cypresshttps://www.cypress.io镜像简介它是一个前端e2e测试工具。在使用npm或yarn安装时，除了NPM源，还需要一个URL下载二进制文件。类似node-sass。镜像源地址/同步方案参考：https://docs.cypress.io/guides/getting-started/installing-cypress.html#Run-binaryhttps://download.cypress.io/desktop.json

在该系列的第一篇文章中，主要介绍了Knative的基本概念及诞生背景，并提到 Knative 主要由 Build、Serving 和 Eventing 三大核心组件组成，本文将重点 Build 的使用方法。具体来说，Build 提供源码到容器镜像的构建能力；Serving 提供 Serverless 应用或函数的部署能力，并通过 istio 实现服务管理，同时提供了容器扩缩容能力；Eventing：提供事件触发通道。Knative 的这三个组件提供了一套完善的 Serverless 方案，让开发者可以只关心自己的代码。提交代码以后，Build 会将源码构建成镜像，Serving 会自动实现应用部署，Eventing 提供事件触发入口，接下来就可以访问到最新应用了。对使用者来说，从源码直接到应用，省去了中间复杂的环节。Build 完全基于 Kubernetes，设计非常灵活，用户可以利用 Build 定制构建流程，虽然官方文档宣称现在 Knaitve 还不能提供完整的 CI/CD 方案，但是利用 Build 的灵活性完全可以实现 CI 平台搭建，这部分内容会在后面的实现中着重介绍。本文，我们把 Build 组件拆开揉碎，全面分享给读者。如果现在手头刚好有一个K8s集群，可以跟着文档尝试操作，整个过程甚至不需要占用一杯咖啡的时间。Build 组件安装Build 可以作为一个独立组件单独安装，只需要在 K8s 的集群中执行以下命令即可：kubectl apply --filename https://github.com/knative/build/releases/download/v0.6.0/build.yaml执行成功以后，可以通过以下命令查看：kubectl get pods --namespace knative-build可以看到，在 knative-build 的 namespace 下，新增了两个容器 build-controller 和 build-webhook，build-controller 是 Build 核心模块，其基本业务流程是监控自己创建的 CRD 资源从而实现构建，build-webhook 和大多数的 webhook 功能一样，通过 webhook 的方式对自己的 api 进行校验。到这里恭喜你，Build 组件已经安装成功了，接下来就可以利用它来进行构建。build 和 buildtemplate构建之前，我们需要先了解两个概念：build 和 buildtemplate。这里的 build 不是 knative 的 Buid 组件，而是 Build 组件通过 CRD 定义的一个资源文件，build 通过自己定义资源文件去控制构建流程，所以说，Build 完全基于 K8s 生态，只要有 K8s 集群就可以完成构建而不需要依赖其他外部组件，同时，yaml 定义的资源文件也可以很轻易的移植到其他集群上去。为了方便理解，我们先看一个 build 的 yaml 文件：apiVersion: build.knative.dev/v1alpha1   kind: Build metadata:   name: kaniko-build   spec:     serviceAccountName: build-bot   // 如果源码或者仓库为公开可以不用创建 serviceAccount     source:    git:      url: https://github.com/my-user/my-repo   // 你的源码仓库地址      revision: master                          // 你的源码分支地址    template:       name: kaniko                                     arguments:    - name: IMAGE      value: us.gcr.io/my-project/my-app         // 构建成功以后镜像存放的镜像仓库地址   以下是其中的几个关键配置：如果想在自己的代码仓库尝试用 build 进行构建，只需要修改上面蓝色的部分即可。看起来，build.yaml 非常简单，而且在 yaml 中也没有看到关于构建过程的体现，是因为在这个 build.yaml 里定义了一个 buildtemplate，buildtemplate 中定义了实际构建过程中的 steps（关于 steps 的内容我们稍后会讲到），当我有多个代码库，或者代码库下有多个分支，抑或是代码想用不同的方式去构建，每次都要定义一个完整的 build 文件就显得非常麻烦，这个时候利用 buildtemplate 可以定义很多构建模板，然后只需要像上面的 build.yaml 一样简单指定代码仓库即可。那么，buildtemplate 是必须的么？当然不是，我们可以直接把 steps 写在 buid.yaml 里，但是 buildtemplate 极大的提高了 build 的灵活性和可移植、可重用性。为了方便快速实现构建，knative 的 build-template 代码库中已经预置了大量的 buildtemplate，包括bazel，buildpacks，kaniko等近十个模板，这里我们先用 Kaniko 的 build-template 体验一下 build 的构建过程。Kaniko 是 Google 推出的构建工具，它基于 Dockerfile 进行构建但是却不需要 docker daemon，我们先来看一下 Kaniko 的 buildtemplate 是什么样子。apiVersion: build.knative.dev/v1alpha1   kind: BuildTemplate   metadata:     name: kaniko   spec:    parameters:  - name: IMAGE      description: The name of the image to push  - name: DOCKERFILE      description: Path to the Dockerfile to build.      default: /workspace/Dockerfile    steps:  - name: build-and-push      image: gcr.io/kaniko-project/executor       args:      - --dockerfile=${DOCKERFILE}    - --destination=${IMAGE}     env:       - name: DOCKER_CONFIG      value: /builder/home/.dockerbuildtempate 中也有几个关键配置：kaniko 的 buildtemplate 十分简单，只有一个 step，然后传入两个参数 DOCKERFILE 和 IMAGE 即可，DOCKERFILE 是工程中 dockerfile 所在的文件路径，IMAGE 是要推送的镜像仓库地址。这两个文件都准备好以后你只需要执行以下两条命令, 一切顺利的话一段时间时候以后，你就可以在你的镜像仓库里看到你刚刚构建好的镜像了。kubectl create -f kaniko.yaml   kubectl create -f build.yaml如果只是想体验一次 Build 带来的基于原生 K8S 的快捷构建，到这里你的体验之旅就已经结束了，如果想问到底执行完以后发生了什么，那就再花点时间看看到底发生了什么？Build 构建实现在上述步骤创建完 build.yaml 以后执行kubectl get pod我们发现多出了一个 pod，用 describe 查看 POD 可以看到以下信息：Name:               kaniko-build-pod-a4f897   Namespace:          default   Controlled By:      Build/kaniko-build Init Containers:  build-step-credential-initializer:Image:          gcr.io/knative-releases/github.com/knative/build/cmd/creds-init@sha256:101f537b53b895b28b84ac3c74ede7d250845e24c51c26516873d8ccb23168ce  .......  build-step-git-source-0:    Image:         gcr.io/knative-releases/github.com/knative/build/cmd/git-init@sha256:ce2c17308e9cb81992be153861c359a0c9e5f69c501a490633c8fe54ec992d53    Args:      -url   https://github.com/lihua871205/2048.git      -revision      master   ......    build-step-build-and-push:    Image:         gcr.io/kaniko-project/executor    Args:      --dockerfile=/workspace/Dockerfile      --destination=swr.cn-north-1.myhuaweicloud.com/l00283074/sample:latestPOD 里边包含三个 Init Containers：build-step-credential-initializer， build-step-git-source-0 以及 build-step-build-and-pushbuild-step-credential-initializer：如果 git 和 docker 需要认证的对 git 和 docker 进行认证build-step-git-source-0：负责将代码拉取到 workspace 下build-step-build-and-push：是用户自己定义的构建 step，它负责将源码构建成镜像从这里，我们可能已经猜到 build 的构建实现，利用 Init Containers 的特性，build 先将 source 中的配置生成一个默认的 build-step-git-source-0 接下来再将用户 step 中配置的信息依次解析成多个 Init Containers，当 POD 运行的时候会依次执行所有的 Init Containers 从而实现代码获取，源码构建的流程。这也回答了上面的两个问题：为什么每个 step 都要有一个 builder？这是 Init Containers 的特性决定的，即使是 Source 这个步骤其实也是使用了 Build-Controller 内置的一个镜像；为什么 build 非常灵活？用户可根据自己的场景，自己定制构建镜像，Build 只提供构建流程，但是不提供构建实现，这也是为什么当前有这么多 buildtemplate 的原因。我们再回顾下 Build 的基本流程：总结Knative 的 Build 利用 init container 实现了一个基于 K8s 生态的构建流程，用户可以自己定制构建场景，或者利用丰富的 build-template 实现构建，它可以作为一个独立的组件减少 K8s 构建的烦恼，更重要的是可以嵌入到 serving 中（偷偷预告一下后面的章节会讲到 build 如何和 serving 集成到一起）形成完整的 Serverless 生态，只有通过 Build 快捷地将源码变成镜像，才能让 serving 有源源不断的“粮草”大展身手。

将kubernetes源加到huaweicloud.com开源镜像站，方便使用。