Portworx Essentials vs. Portworx Enterprise:

https://www.iqiyi.com/v_19rzfuk1yw.html

欢迎回到Portworx讲解视频系列，我是Ryan Warner。今天我们来介绍一下Portworx Essentials版本，以及与Portworx Enterprise版本的区别。

 

Portworx Essentials是在K8S上运行数据管理的最必要的功能组合，他的优势是永久免费，如果你不想完整的导入PortworxEnterprise版本，你仍然可以使用Portworx，虽然有一些功能限制，如果你现在的集群规模较小，或者刚刚开始搭建K8S，可以先不用急着购买Portworx Enterprise，仍然可以获得数据管理的重要功能。

 

接下来我来介绍一下Portworx Enterprise的具体功能有哪些。你可以在任何需要的时候升级到Portworx Enterprise。这里我列出了Portworx Enterprise的主要功能，例如，支持1000个节点，100个容器每节点，支持百万级别的卷，30天的免费试用，期间可以获得Portworx的完整功能，7*24，365天的支持，包括所有的组件：PX-DR，PX-Autopilot，PX-Security，PX-Migrate，PX-Backup。所有的企业级功能，当你需要在成规模的集群上运行有状态的关键应用。

 

Portworx Essentials，适合中小型企业客户或者是简单的K8S环境，Portworx Essentials，只支持最大5个节点，最大5TB存储，也就是1TB每节点，每卷容量的上限也是1TB/卷，一个节点可以创建单一的PVC，1TB。适合比如一个跑在3~5个节点上的应用，或者适合一个小型的数据库，会使用更少的存储，这里20G，那里20G，这种情况下，支持每节点30个容器，而Portworx Enterprise是每节点100个容器，你会有社区技术支持，可以访问Portworx Central、访问论坛、提交支持申请，这样来利用社区的技术资源，但是不同于Portworx Enterprise可以有企业级的支持。

 

如果需要组件功能（PX-DR，PX-Autopilot，PX-Security，PX-Migrate，PX-Backup），则需要通过购买Portworx Enterprise来实现，可以通过Portworx Essential来实现一些安全功能，每卷允许做5次快照，给与用户一些机会来保护应用，还允许每天一次的云快照，如果你需要把数据保存在云中，如对象存储中，来为K8S集群达到一定的容灾功能，可以每天做云快照一次，你也可以使用加密功能，但是也只能为集群使用单一的密钥，而不是像Enterprise那样，更复杂的卷和密钥的配置，

 

Portworx Essential仍然是一个很棒的解决方案，只是适用的集群规模会比较小，也适用于小规模的生产系统，如果规模扩大以后，我们还是建议升级到Portworx Enterprise，以上我们介绍了Portworx Essentials，欢迎下载试用，它是永久免费的，下次再见，谢谢！

 

Portworx Kubemotion：在OpenShift集群间迁移有状态应用

Portworx是一个支撑K8S有状态应用的持久存储和数据管理平台。通过Portworx，它为有状态应用提供了一个单一的数据管理层，从而用户可以在任何底层架构上运行类似数据库这样的有状态应用。

Kubemotion是Portworx的核心功能之一，发布在Portworx企业版2.0中。它赋能K8S用户在集群间迁移应用和数据、备份和恢复、以及做蓝绿部署。（https://docs.portworx.com/portworx-install-with-kubernetes/migration/kubemotion/）

下面我们介绍如何在红帽OpenShift集群之间，迁移有状态应用的持久卷和相关K8S资源。

背景

在企业客户中，一个常见的场景是：在一个云区域中运行研发测试环境，而在另一个云区域中运行生产环境。研发测试环境通常会选择距离开发团队比较近，以降低网络延迟，而生产环境则会选择离用户比较近。

K8S的无状态应用迁移相对比较容易，但迁移有状态应用是一个挑战。

在演示中，我们会在AWS位于美国东部（俄亥俄），和美国西部（俄勒冈）的两个数据中心的Openshift集群间，迁移K8S资源。美国东部区域（俄亥俄）部署的是研发测试环境，美国西部区域（俄勒冈）部署的是生产环境。在系统的测试环节完成后，开发团队将使用Portworx和Kubemotion，把存储卷和应用资源，从研发测试环境，迁移到生产环境中。

研发测试环境和生产环境

我们有两个红帽OpenShift集群，分别是研发测试环境、以及生产环境，位于AWS的两个不同区域上，两个环境都安装了最新版本的Portworx集群，并且正在运行。上面的OpenShift集群代表了运行在AWS东部区域（俄亥俄）的研发测试环境。

上面的OpenShift集群代表了运行在AWS西部区域（俄勒冈）的生产环境。

现在有一个基于LAMP的内容管理系统（CMS）运行在研发测试环境上，我们需要把它迁移到生产环境里。

研发测试环境里部署了MySQL和WordPress，它们都位于CMS命名空间里。

关于如何在OpenShift上配置高可用的WordPress，可以参考这里的文档。（https://www.portworx.com/run-multi-tenant-ha-wordpress-platform-red-hat-openshift/）

Portworx存储集群支撑了附加在这些Pod上的持久卷。

下面的卷附加到了MySQL pod上。

对于WordPress CMS, 有个共享的Portworx卷附加到了Pod上。

配置好的应用，可以通过WordPress相关的服务来访问。

准备源环境和目标环境

在我们迁移之前，我们需要配置源集群和目标集群。按照下面的步骤来准备相关的环境。

创建对象存储的访问身份验证我们需要在源集群和目标集群上都创建对象存储的访问身份验证信息。我们需要获得目标集群的UUID，它会被附加在访问身份的名称上。

为了完成这一步，你需要AWS账户的访问密钥和Secret密钥。如果你已经配置好了AWS CLI，可以在这里发现这些密钥。~/.aws/credentials

回到生产环境集群，运行下面的命令来复制UUID。

PX_POD=$(oc get pods -l name=portworx -n kube-system -o jsonpath='{.items[0].metadata.name}')
oc -n=kube-system exec $PX_POD -- /opt/pwx/bin/pxctl status

 

记下集群的UUID，放在一个安全的地方。

我们在生产环境内，来创建生产环境集群的身份验证信息。

oc -n=kube-system exec $PX_POD -- /opt/pwx/bin/pxctl credentials create \
	--provider s3 \
	--s3-access-key  \
	--s3-secret-key  \
	--s3-region ap-southeast-1  \
	--s3-endpoint s3.ap-southeast-1.amazonaws.com clusterPair_c02528e3-30b1-43e7-91c0-c26c111d57b3

确保身份验证信息的名称按照这样的格式：‘clusterPair_UUID’。

回到研发测试集群，重复操作来创建身份验证信息。

获取目标集群的Token

下一步是获取生产环境集群的Token，它会被用来创建集群配对的YAML文件。

到生产环境集群，运行下面的命令来访问Token。

PX_POD=$(oc get pods -l name=portworx -n kube-system -o jsonpath='{.items[0].metadata.name}')
oc -n=kube-system exec $PX_POD -- /opt/pwx/bin/pxctl cluster token show

记下集群Token，放置在一个安全的地方。

为Portworx服务获取负载均衡的端点

我们还需要生产环境集群上的，与Portworx服务关联的负载均衡的DNS名称。我们可以通过下面的命令得到。

oc describe svc portworx-service -n kube-system

到这里，你已经准备好下面的数据了：

1.   目标集群的Token

2.   指向Portworx服务的负载均衡的CNAME

创建集群配对参数

我们从生产环境（目标集群）来创建YAML文件。并且把它应用到研发测试环境（源集群）。

确保你在在生产环境中，运行下面的命令。

storkctl generate clusterpair -n cms prodcluster > clusterpair.yaml

打开clusterpair.yaml，在选项中增加下面的细节信息。它们反映了目标集群里的负载均衡的IP地址或者DNS名称，以及与目标集群关联的Token。

为Kubemotion进行集群配对

通过为源集群配置配对参数，我们可以把集群进行配对。

我们回到源集群（研发测试环境），来进行集群配对。

oc apply -f clusterpair.yaml
oc get clusterpair -n cms

<pre>oc getclusterpairs</pre> 的输出确认了配对已经成功。

验证配对状态

我们可以通过storkctl CLI来验证配对状态。确保存储的状态，和调度器的状态都是正常，没有错误。

storkctl -n=cms get clusterpair

我们验证了，源集群和目标集群已经配对成功。

现在我们开始迁移。

从源集群向目标集群迁移CMS应用

在研发测试环境下，通过下面的步骤开始CMS应用的迁移。

开始迁移

用下面的内容创建一个名为migration.yaml的YAML文件。

apiVersion: stork.libopenstorage.org/v1alpha1
kind: Migration
metadata:
  name: cmsmigration
  namespace: cms
spec:
  # This should be the name of the cluster pair created above
  clusterPair: prodcluster
  # If set to false this will migrate only the Portworx volumes. No PVCs, apps, etc will be migrated
  includeResources: true
  # If set to false, the deployments and stateful set replicas will be set to 0 on the destination.
  # There will be an annotation with "stork.openstorage.org/migrationReplicas" on the destinationto store the replica count from the source.
  startApplications: true
  # List of namespaces to migrate
  namespaces:
  - cms

这里包括一些很重要的信息，例如集群配对的名称、迁移中包括的命名空间，需要被迁移的资源类型。

把YAML文件提交到研发测试集群，来开始迁移。

oc apply -f migration.yaml
migration.stork.libopenstorage.org/cmsmigration created

监控迁移的过程

使用storkctl我们来监控迁移的过程。

storkctl get migration -n cms

 

一旦迁移完成，storkctl 会报告最后迁移到目标集群的卷的数量以及资源。

通过下面的命令，可以得到迁移过程的详细信息。

oc describe migration cmsmigration -n=cms
% oc describe migration cmsmigration -n=cms
Name:         cmsmigration
Namespace:    cms
Labels:
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"stork.libopenstorage.org/v1alpha1","kind":"Migration","metadata":{"annotations":{},"name":"cmsmigration","namespace":"cms"}...
API Version:  stork.libopenstorage.org/v1alpha1
Kind:         Migration
Metadata:
  Creation Timestamp:  2019-11-08T02:33:44Z
  Generation:          9
  Resource Version:    346702
  Self Link:           /apis/stork.libopenstorage.org/v1alpha1/namespaces/cms/migrations/cmsmigration
  UID:                 2eeb5d56-01d0-11ea-a393-02fec625b80a
Spec:
  Admin Cluster Pair:
  Cluster Pair:        prodcluster
  Include Resources:   true
  Include Volumes:     true
  Namespaces:
    cms
  Post Exec Rule:
  Pre Exec Rule:
  Selectors:
  Start Applications:  true
Status:
  Finish Timestamp:  2019-11-08T02:34:56Z
  Resources:
    Group:      core
    Kind:       PersistentVolume
    Name:       pvc-ac60362f-0170-11ea-8418-06c5879a6a7a
    Namespace:
    Reason:     Resource migrated successfully
    Status:     Successful
    Version:    v1
    Group:      core
    Kind:       PersistentVolume
    Name:       pvc-c5dd1955-0170-11ea-a393-02fec625b80a
    Namespace:
    Reason:     Resource migrated successfully
    Status:     Successful
    Version:    v1
    Group:      core
    Kind:       Service
    Name:       mysql
    Namespace:  cms
    Reason:     Resource migrated successfully
    Status:     Successful
    Version:    v1
    Group:      core
    Kind:       Service
    Name:       wordpress
    Namespace:  cms
    Reason:     Resource migrated successfully
    Status:     Successful
    Version:    v1
    Group:      core
    Kind:       PersistentVolumeClaim
    Name:       px-mysql-pvc
    Namespace:  cms
    Reason:     Resource migrated successfully
    Status:     Successful
    Version:    v1
    Group:      core
    Kind:       PersistentVolumeClaim
    Name:       px-wp-pvc
    Namespace:  cms
    Reason:     Resource migrated successfully
    Status:     Successful
    Version:    v1
    Group:      apps
    Kind:       Deployment
    Name:       mysql
    Namespace:  cms
    Reason:     Resource migrated successfully
    Status:     Successful
    Version:    v1
    Group:      apps
    Kind:       Deployment
    Name:       wordpress
    Namespace:  cms
    Reason:     Resource migrated successfully
    Status:     Successful
    Version:    v1
    Group:      route.openshift.io
    Kind:       Route
    Name:       wp
    Namespace:  cms
    Reason:     Resource migrated successfully
    Status:     Successful
    Version:    v1
  Stage:        Final
  Status:       Successful
  Volumes:
    Namespace:                cms
    Persistent Volume Claim:  px-mysql-pvc
    Reason:                   Migration successful for volume
    Status:                   Successful
    Volume:                   pvc-ac60362f-0170-11ea-8418-06c5879a6a7a
    Namespace:                cms
    Persistent Volume Claim:  px-wp-pvc
    Reason:                   Migration successful for volume
    Status:                   Successful
    Volume:                   pvc-c5dd1955-0170-11ea-a393-02fec625b80a
Events:
  Type    Reason      Age                From   Message
  ----    ------      ----               ----   -------
  Normal  Successful  82s                stork  Volume pvc-ac60362f-0170-11ea-8418-06c5879a6a7a migrated successfully
  Normal  Successful  82s                stork  Volume pvc-c5dd1955-0170-11ea-a393-02fec625b80a migrated successfully
  Normal  Successful  78s                stork  /v1, Kind=PersistentVolume /pvc-ac60362f-0170-11ea-8418-06c5879a6a7a: Resource migrated successfully
  Normal  Successful  78s                stork  /v1, Kind=PersistentVolume /pvc-c5dd1955-0170-11ea-a393-02fec625b80a: Resource migrated successfully
  Normal  Successful  78s                stork  /v1, Kind=Service cms/mysql: Resource migrated successfully
  Normal  Successful  78s                stork  /v1, Kind=Service cms/wordpress: Resource migrated successfully
  Normal  Successful  78s                stork  /v1, Kind=PersistentVolumeClaim cms/px-mysql-pvc: Resource migrated successfully
  Normal  Successful  78s                stork  /v1, Kind=PersistentVolumeClaim cms/px-wp-pvc: Resource migrated successfully
  Normal  Successful  78s                stork  apps/v1, Kind=Deployment cms/mysql: Resource migrated successfully
  Normal  Successful  77s (x2 over 78s)  stork  (combined from similar events): route.openshift.io/v1, Kind=Route cms/wp: Resource migrated successfully

在生产环境上验证迁移

回到生产环境，我们来检查CMS命名空间里的所有资源。

oc get all -n cms

你可以通过为WordPress Pod使用port-forwardding，来访问应用。

小结

Kubemotion为有状态应用增加了迁移功能。它可以在本地环境和云环境之间，以及多云环境之间，无缝的迁移卷。

当您将Ansible与AWS结合使用时，维护清单文件将是一项繁重的任务，因为AWS经常更改IP，自动缩放实例等。但是，有一个简单的解决方案就是ansible动态清单。它基本上是一个Python脚本，当您运行ansible命令时会进行API调用以获取实例信息。这将为您提供动态清单详细信息，这些信息可以用来方便管理AWS基础架构。

设置Ansible AWS动态清单

1.使用pip安装boto库。如果您尚未安装pip，则可以按照此文档进行安装–> 安装python pip

pip install boto

2.将清单脚本下载到/ etc / ansible目录。

Wget https://raw.github.com/ansible/ansible/devel/contrib/inventory/ec2.py

3.使文件可执行。

chmod + x ec2.py

4.将ec2.ini文件下载到/ etc / ansible目录。

https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/ec2.ini

5. ec2.ini文件具有默认的AWS配置，可通过ec2.py文件读取。因此，请注释掉并配置必要的参数，以免查询时间过长。这样的例子就是“ regions”参数。默认情况下，该值为“ all”。这样可以对所有区域进行API调用。因此，最好只提及您使用的特定aws区域。

在[credentials]部分下，您需要提及abos访问密钥和私钥，以便boto库进行API调用。

或者，您可以在家里创建一个凭证文件，如下所示。

touch ~/.aws/credentials

打开凭证文件，然后如下所示进行输入。

[default]

aws_access_key_id = YOUR_ACCESS_KEY

aws_secret_access_key = YOUR_SECRET_KEY

注意：如果您正在使用AWS实例进行此设置，并且具有具有访问AWS服务权限的IAM角色，则无需将访问密钥和秘密密钥添加到凭证文件中

6 现在，使用以下命令测试清单配置。

./ec2.py –list

应该获得如下所示的输出。

{

“ _meta”：{

“ hostvars”：{}

}

}

如果您有一些实例正在运行，则将获得包含所有实例详细信息的输出。

7.如果要将动态清单用作默认的ansible清单，则需要编辑/ etc / ansible目录中存在的ansible.cfg文件，并在ansible.cfg中搜索清单参数。如下所示更改库存参数值。

inventory      = /etc/ansible/ec2.py

现在，您可以对动态清单资源运行正常的ansible命令。例如，以下命令将对使用动态清单获取的所有正在运行的ec2实例运行ping命令。

ansible all -m ping

关注每周二晚八点JFrog在线课堂，获取更多技术分享。关注微信公众号“JFrog杰蛙DevOps”，获取课程通知

 

报名链接：https://amazonaws-china.com/cn/about-aws/events/0628-eks-container/?trkCampaign=0628-eks-container&trk=Jfrog

Portworx技术视频系列：通过PX-AutoPilot自动扩展存储池容量

https://v.qq.com/x/page/w3102db86te.html

欢迎来到Portworx技术系列视频，我是Ryan Wallner。今天我们来介绍一下存储容量管理。Portworx Autopilot，我们会专门介绍一下存储池扩充、容量管理，这样可以让用户基于一些提前设定的规则引擎，自动的添加磁盘。Portwortx Autopilot可以自动化的管理容量，自动化的运维，例如添加磁盘，扩充PVCs，或者在存储池里扩充磁盘。这些操作可以通过脚本自动执行，也可以手动方式，但都是以K8S云原生的方式来进行的，定义YAML文件，给予Portworx权限来做这些事情。

当你完成了Portworx的配置，为每个节点配置了每个100G的磁盘，假如是云中，我们使用EBS，这样我们就为PVCs设定了一个Portworx存储池，总共300G。应用会使用PVCs，后续可能有更多的应用，数据库，服务会运行在K8S上，当它们开始使用存储容量的时候，假设它们使用了150G的空间。这是所有存储容量的一半。我们如何来管理这些容量？如何触发动作呢？我们来看一下Autopilot是怎么做的。

当你安装了Portworx，开始使用Autopilot，你会需要Prometheus，Prometheus的作用，是收集K8S里应用运行情况的信息，Portworx自身也使用Prometheus，方式是Portworx提供API，含有Prometheus端点，这个端点，会向Prometheus提供运行情况的信息，Prometheus就可以看到比如卷的数量、总体容量、已经使用了多少，CPU、内存这些。

AutoPilot，我们用AP来表示，会接入Prometheus，并且获取状况信息，这样AutoPilot根据状况信息，和事先制定的规则，对Portworx的运行进行自动化管理，现在我们对管理控制的流程有了概要性的了解，以及Autopilot的工作原理，我们需要创建一些规则，用Prometheus能够理解的表达，同时Autopolit可以去执行，假设，已经使用的字节，和总共的字节数，表明了我们还有多少容量可以使用。我们设定一个规则：如果我们剩下的容量已经不到40%了，也就是我已经使用了60%的容量，就会触发动作，来扩充我们的集群。

扩充的方式是增加磁盘。我们可以制定一些规则增加额度的限制，例如，每次当使用到60%容量时，这种情况可能会经常发生，我们可以设定，触发增加50%容量的动作，就是总体容量增加50%。也可以增加一些限制，例如，每个存储池的上限不要超过2TB，这是考虑你有成本限制的情况。这就是通过Autopilot来设定一些自动化的规则，以及设定限制。

还有其他配置方式，主要的配置方式就是规则、动作、和方式，当存储池增长到了60%，Prometheus会探测到，Autopilot就会触发规则，来进行相应的动作，这里动作就是增加存储池容量，增加磁盘会增加存储池容量50%，达到450G。这样我们的容量使用率就不再是60%了，Portworx增加总容量后，它就会低于60%，这个规则仍然是有效的，因为后续可能会进一步需要存储容量。

​​​​​​​这里我们演示了，Autopilot如何通过规则和动作，自动化的控制下层的存储，如AWS, Azure,Vmware Vsphere，部署磁盘，加到存储池里面，确保一切都可以自动化的有序进行。这里我们介绍了增加磁盘的类型，直观的可以看到通过Portworx增加了存储池的容量，为PVCs服务。后续我们还会介绍其他类型，比如当磁盘达到使用率的阈值的时候，增加单个磁盘的容量，而不是增加新磁盘，以及介绍PVCs。上面我们介绍了Autopilot，自动增加磁盘容量，以及存储池容量，希望对您有用，谢谢！

Portworx的商业价值

减少基础架构成本30~60%，减少风险，加速容器化应用。

在一个快速变化、多云架构的环境中，企业快速部署新应用的压力越来越大。为了达到敏捷性，企业开始采用更先进的以容器为基础的应用架构。Gartner统计在2020年，50%的国际级公司会在生产系统中使用容器技术。2020年，超过20%的企业存储资源会被用以支撑容器化应用，而这一数字在之前不超过1%。然而，传统的存储解决方案对分布式的容器化环境来说过于复杂、成本高昂、且不稳定。

这也是为什么如GE、Comcast、Verizon等大型企业信任Portworx来管理它们的关键应用数据。完成跨多云、零宕机时间、和零数据损失，同时极大的降低基础架构的成本。

全球财富1000强公司信任Portworx为其生产系统服务服务:

减少计算资源成本 40~60%

容器比虚拟机更加轻量。在不同的基础架构环境下，我们可以增加每主机支撑应用的密度至少4倍以上。由于平均应用密度的增加，企业通过容器技术降低了至少一半的服务器成本。Portworx帮助用户增加了同一主机上可运行有状态应用的数量，如数据库这样的有状态应用。在很多例子中，当客户需要在多节点下运行有状态应用的情况下，Portworx帮助客户减少了40~60%的必须的容器数量。把有状态应用向容器转移的好处是非常明显的，然而, 运行有状态应用要求企业解决传统存储解决方案和云上块存储无法解决的问题。例如，使用云计算的块存储无法在每个虚拟机里运行50或100个数据库，因为Linux操作系统限制了每主机能支持的块存储卷的数量不能高于40。更重要的是，相对于虚拟机，容器更加灵活：快速启动、关闭、自动在可用资源上漂移等。在这样的模式下，手动方式的部署和管理效率就显得十分低下。为了应用容器化节省基础架构成本，迫切需要云原生化、针对容器架构的存储解决方案。

除了帮助容器化关键应用解决存储问题，并且节省成本，Portworx在保持同样高可用水平和同样性能水平下，通过减少多节点有状态服务上的必要的容器数量，进一步减少基础架构的成本。例如，一个典型的数据库，如Kafka或者PostgreSQL，会通过复制集方式，在集群上的其他主机上存储数据副本。如果某一个主机上的数据损坏，数据库将会从集群的其他主机上重新获取数据。这种方式属于应用层面的复制集，并且产生了两类相对较高的成本：第一，应用层面的复制消耗了本来可以被数据库使用的I/O，这样就会降低应用的速度。第二，这使用户不得不运行超出必要的容器数量，来满足数据库的需要，因此用户不得不使用更多的计算资源。

从下面的测试中，我们可以得出：使用Portworx后，可以通过只使用1个容器部署MongoDB，而达到通常情况下3个容器部署MongoDB的同等性能和同等可靠性。这样可为每个数据库节省60%的计算资源。

上表我们总结了使用MongoDB的测试结果。相比于单一的MongoDB容器，Portworx提高了写操作的性能319%。相比于3容器的MongoDB复制集部署，Portworx提高了写操作性能10%，但是只消耗1/3的计算资源。类似MongoDB这样占用物理资源较高的应用，使用Portworx带来的成本节省可以超出1000美金/每月/每数据库。远远超出Portworx本身的成本。

客户有时希望使用应用复制来增加多主机环境下的读数据速度。Portwork同样可以提供巨大价值：减少复制数量从5容器到3容器（40%的成本降低），或者从8容器到5容器（38%的成本降低），在这种情况下，Portworx帮助有状态应用减少了所必须的计算资源。在容器化带来的成本降低基础上，又带来了更多的成本降低。

Portworx增加性能、减少资源消耗。对于比较耗费物理资源的数据库，如MongoDB，可以达到超过1000美金/每数据库/每月的成本降低，远远超出Portworx本身的成本。

减少30%的存储成本

除了减少计算资源的成本，取决于不同配置情况，Portworx云原生存储还可以降低至少30%的存储成本。是通过如下的机制实现的：

减少了存储的过度部署

Portworx动态卷部署、按需调整存储容量，可以帮助企业避免对存储资源的过度部署。高密度的应用集群通常会过度占用存储。实际上，通过Portworx，可只在需要时动态增加存储，而不影响应用的SLA等级。例如，一个内部IT为10个开发团队每团队配置1个100GB的PostgreSQL数据库，使用传统存储解决方案的情况下，需要在初始阶段部署1TB的存储，但实际上很大一部分存储是没有被使用的，如果使用Portworx，可以按照实际需要来调整存储的部署，因此只有在真正需要这部分存储时才会部署，这样可能就只用到700GB。当开发团队需要的情况下，也可以通过扩充节点（裸金属最常用的扩容方式），或者扩充块存储（云计算最常用的扩容方式），来增加额外的存储。

Portworx帮助有状态应用减少了计算资源。在容器化带来的成本降低基础上，又带来了更多的成本降低。

存储分级化管理

通过把应用负载调整到最具性价比的存储上，可以获得客观的成本节省。使用AWS为例，SSD（12美分/GB），是HDD（5.4美分/GB）价格的两倍。非关键应用也可以转移到更经济的对象存储上（2.3美分/GB），成本是HDD的一半。通过Portworx，来部署一个动态的、分级管理的存储，包括闪存、硬盘和对象存储，可以帮助客户在维持应用SLA不变的情况下，减少大量的存储成本。

把负载部署在正确类型的存储上、可以节省大量的成本

通过减少存储的过度部署，以及存储分级化管理，可以节省超过30%的存储成本

通过更有效的使用EBS，减少对存储的过度部署，以及把非关键应用负载转移到更低成本的二级存储，可以取得至少30%的成本节省。例如，如果我们保守的假设可以减少30%的EBS卷部署，并且我们把20%的非关键负载从EBS SSD转移到EBS HDD上，我们就会节省38%的总存储成本，对于200T的存储来说，这代表每年10万美元。

在内部运维、和外部供应商提供的支持服务上，每年可以节省至少180万美元

由于数据库和数据分析越来越先进，平均来说，企业会在容器平台上至少运行10个以上的数据库或数据服务。这些数据服务包括SQL数据库：例如MySQL、PostgreSQL；和非SQL数据库：如MongoDB、Cassandra、Couchbase；以及流式分析工具：如HDFS、Spark、Kafka、TensorFlow等，还有比较常见的Redis、 ElasticSearch等。在这种量级的数据服务上，由于运维管理的复杂，通常需要专业的DevOps经验和技能，或者是由数据服务的供应商提供专业服务来完成。对于典型的10个以上的数据库或者数据服务，运维的人力成本通常会超过150万美元。供应商提供的支持服务的成本通常也要几十万美元。这还没有考虑到在竞争激烈的人力市场中，有可能招募不到所需的工程师人才，这会增加我们的运维管理的风险，从而更加依赖数据库供应商的支持服务。由于PX-Enterprise 为有状态应用提供了一个独立的数据管理和存储管理层，一个小型的运维团队就可以轻松的同时运行和管理多个数据库/数据服务，不需要过多的数据库专业技能。PX-Enterprise 可以自动化的针对有状态应用进行部署、升级、扩容、高可用、备份、容灾和恢复，对数据库供应商的支持服务的依赖也会大幅降低。因此，通过PX-Enterprise 为10个以上的有状态服务提供存储支持，通常可以帮助企业在内部运维和外部供应商服务上节省200万美元以上，远超出Portworx自身的成本。

通过PX-Enterprise大幅节省成本

降低容器项目的失败风险

降低基础架构的成本很重要，在高度竞争的商业环境下，仅仅降低成本并不足以保证商业的成功。容器技术是敏捷IT架构的重要核心，但是如没有已被成功验证有效的云原生存储和数据管理，我们无法大量的把应用迁移到容器环境中，也就无法发挥容器技术的最大优势，由此可能导致几百万美元的投资未能达到预期目标，甚至可能导致技术投资的失败。

Portworx降低集成的风险

为了成功的部署有状态应用，需要对基础架构：包括计算、网络、存储、容器调度、应用等进行有效集成和管理。由于软硬件部分较多，集成失败的风险较高。尤其是对于关键有状态应用，如数据库来说，失败概率更高。Portworx是按照云原生方式针对容器技术专门设计的，它可以自动的管理运维中的错误，包括：节点失败、网络分区错误、磁盘错误等，而采用传统方式则需要极多的人工干预和随之而来的成本上升。通过提供应用一致性的快照，Portworx提供了真正的多云备份和恢复。

降低性能风险

许多存储解决方案宣称支持容器技术，然而当真正部署和测试这些方案的时候，它们并不适用于高性能的数据库负载。例如，GlusterFS的 CPU 和内存用量，会随着卷数量的增加，线性增长，此时I/O能力会大幅降低。Ceph, 通过跨主机数据连接提供高可用，无法运行容器的超融合，会产生网络延迟。

每个新增的GlusterFS 卷会增加CPU和内存的用量，严重降低基础架构资源的利用率

不同于传统的存储解决方案，Portworx为裸金属服务器或虚拟化环境下的高性能数据库提供高I/O能力。Portworx 赋能客户通过运行超融合架构，使数据和容器运行在同一批物理主机上，从而最大化提高性能。Portworx通过提供复制集在集群中的位置的调度信息，从而在调度和未调度的运维情况下，都能保持超融合状态。这种方式下，如果没有本地数据的副本，你的容器不会被调度到主机上。

结论

新应用越来越多，上线压力越来越大，Portworx帮助企业加速应用容器化，并且大幅降低基础架构成本和运维成本。这也是为什么GE、Comcast、Verizon等领军企业信任Portworx来为容器化关键业务应用提供数据管理。

通过更有效的管理基础架构，Portworx可以帮助有状态应用减少计算资源成本40~60%，减少存储成本至少30%。Portworx还可以通过帮助有状态应用自动化的管理系统错误、保持系统一致性、高性能、来降低容器化应用的风险。请通过 portworx.com/request-a-demo进行产品演示。

一、背景

Golang开发者非常关心开发应用的安全性。随着Go Module应用越来越广泛，Golang开发者需要更多的方式来确保这些公共共享文件的安全。Golang1.13版本在创建Go Module时，通过增加go.sum文件来验证之后从GOPROXY再次访问到的该Module是否曾被篡改。这个机制有助于保证Module的完整性。但是，当初次创建并提交Go Module时，如果原始文件中被引入了恶意代码，这种安全漏洞还是不能被发现和预警的。

Go Module的安全漏洞影响了很多项目和Go开发者。随着CI/CD流程中“左移”实践的推广，对于Go开发者来说，尽早跟踪和报告Go Module之中的安全漏洞变得越来越重要。幸运的是，GoCenter（https://search.gocenter.io）作为Golang的中央仓库，为Go开发者提供大量公共共享Go Module的同时，也通过集成JFrog Xray安全扫描的能力，帮助Go开发者检测、跟踪并报告仓库中Go Module包含的安全漏洞。

二、报告安全漏洞

任何应用系统，在其开发的生命周期中，都应该持续监视安全漏洞，任何人发现了安全漏洞都应及时报告，以便其修复措施能够被更多的组织和开发者分享与跟踪。已知安全漏洞通常利用CVE（Common Vulnerability and Exposures, 常见漏洞及披露）来分类和跟踪，这是一个用于公开披露安全漏洞信息的列表。每个CVE信息包含一个标准标识序号（CVE ID）、一个状态指示器、对该漏洞的简短描述，以及与漏洞报告及建议相关的索引。

CVE不是漏洞数据库。相反，CVE旨在允许漏洞数据库和其他工具链接在一起，并促进安全工具和服务之间的比较。美国国家漏洞数据库（NVD，National Vulnerability Database）是一个免费的、公开的漏洞数据库，它使用CVE列表的标识序号，并包含漏洞的修复程序、漏洞级别评分，以及其他和每个漏洞相关的信息。

每一个被检测到的安全漏洞都必须报告给CVE编号颁发机构（CNA，CVE Numbering

Authorities），并附上详细的文档解释该漏洞的影响，以及至少一个受影响的代码库，然后才能将其识别为已知漏洞并分配一个CVE ID。作为参考，CVE ID的格式通常为：CVE前缀 + 年 + 任意数字。以下是CVE ID的示例：

三、保护Go Module安全的数据复杂性

确保Go Mudule的安全可能是一项棘手的任务，特别是由于Go Module和Go Package之间的关系。一旦收到Go Module的安全数据，就很难将该数据与特定的Module版本相关联。这是因为安全漏洞存在于Package级别，但是却报告在Module级别上。这可能会给人留下整个Module都容易受到攻击的印象。但事实并非如此，除非您使用易受攻击的Package数据，否则Module将保持安全。

让我们以上图中的CVE-2020-10660 为例。以下是1.3.4版变更日志的摘录，详细介绍了此漏洞的影响：

gopkg.in/hashicorp/vault.v0和github.com/hashicorp/vault都受到了HashiCorp Vault和Vault Enterprise0.9.0到1.3.3版本中的CVE-2020-10660的影响。在使用这些Package时，在某些情况下，它们可能使实体的组成员无意间包含了该实体不再具有权限的组。Vault Enterprise中发现的另一个漏洞是，在某些情况下，现有的嵌套路径策略可能会提供对事后创建的命名空间的访问权限。幸运的是，在版本1.3.4中对这些漏洞进行了修复。

如上例所示，修复是在github.com/hashicorp/vault内进行的。Module

istio.io/istio在其go.mod文件里记录了对github.com/hashicorp/vault的依赖。通常，您会认为istio.io/istio的安全性也会受到威胁。但是它仅仅使用了package github.com/hasicorp/vault/api，因此其代码是不受此漏洞的影响的。请参考下面的源代码：

四、减少软件的安全漏洞

现在您已经了解了如何报告Go

Module安全漏洞的过程，以及有关安全数据复杂性的一些详细信息，让我们看看如何在将来的开发中减少这些威胁。

首先，让我们看一下GoCenter中的Go Module：github/hashicorp/vault。

根据CVE数据，JFrog Xray能够扫描一个go.mod文件里包含的所有在GoCenter中保存的依赖，并识别其中包含的每个安全漏洞。GoCenter在“依赖关系”选项卡上显示这些Xray数据，并提供依赖关系树上各个级别里易受攻击Module的详细信息。您会在每个易受攻击的Module旁边看到一个警示的三角形。然后，您可以单击这些易受攻击的Module并跳转到安全页面。在这里，查看“版本”选项卡可以查找该模块的安全版本，以便您可以在go.mod文件中对其进行升级。

一旦确定了所有组件和依赖项，它们的信息就会与其他漏洞源和数据库进行交叉引用，以提醒您任何潜在的威胁。GoCenter上提供了免费的针对Go Module的基本Xray漏洞扫描，如“安全性”选项卡所示：

五、GoCenter助力Go开发者保持应用安全

GoCenter是公共GOPROXY和中央仓库，具有70万+的Go Module版本。将GoCenter用作GOPROXY时，可以确保下载的代码版本是来自正确源代码的正确版本。GoCenter作为您的GOPROXY可与Go命令无缝协作，并具有安全、快速、可用和存储高效的优势。

许多Golang开发者还可以使用VS Code的免费JFrog扩展，将GoCenter的漏洞信息直接引入其IDE中。

随着CI/CD流程中“左移”实践的推广与落地，GoCenter的安全功能可以帮助您确定要导⼊的公共Go Module版本中是否存在易受攻击的依赖项，进而帮助您保持开发应用的安全性。

 

更多技术分享可以关注我们在新课堂

关注微信公众号：JFrog杰蛙DevOps，获取课程通知

 

前言

随着 Go 语言的深入使用，其依赖管理机制也一直是各位 Gopher 热衷于探讨的话题。Go 语言的源码依赖可通过 go get 命令来获取，但自动化程度不高，于是官方提供了 Dep 这样的自动化批量管理依赖的工具。虽然 Go 语言的依赖管理在很多方面还是不如人意，但整个体系正在日趋完善，本篇就将从最基本的依赖管理场景出发，一同探讨 Go 语言依赖管理的一些最佳实践。

Go 依赖管理的基本思路

在 Go 语言中，我们通过 go get 命令将 GitHub 或者 Google Code 上的代码下载到本地指定目录，然后在开发代码中通过 import 的形式引用本地的代码。

Go 语言可以通过直接分析代码中的 import 语句来查询依赖关系。go get 命令在执行时，就会自动解析 import 来安装所有的依赖。那么下载的依赖在本地是如何存储的呢?

这里就涉及到 Go 语言的 WORKSPACE 概念，简单来说就是通过 GOPATH 环境变量来设置 Go 代码的位置。一般来说，GOPATH 目录下会包含 pkg、src 和 bin 三个子目录，这三个目录各有用处。

bin 目录用来放置编译好的可执行文件，为了使得这里的可执行文件可以方便的运行，在 shell 中设置PATH变量。

src 目录用来放置代码源文件，在进行 import 时，是使用这个位置作为根目录的。自己编写的代码也应该放在这下面，不同的项目放在不同的目录下进行管理。

pkg 用来放置安装的包的链接对象(Object)的。这个概念有点类似于链接库，Go 会将编译出的可连接库放在这里，方便编译时链接。不同的系统和处理器架构的对象会在 pkg 存放在不同的文件夹中。

当项目在 src 目录下管理时，多个项目可能都会使用相同的依赖，如果每个项目都存一份依赖显然会带来大量的冗余，这里我们推荐一个设置 GOPATH 环境变量时的小技巧。

这样第三方包就会默认放置在第一个路径中，而你可以在第二个路径下编写自己的代码，多个项目共享一份依赖。

dep – 官方 Go 依赖管理工具

dep 是 Go 语言官方提供的依赖管理工具，跟其他依赖管理工具类似，都是通过一个文件描述依赖的坐标信息，然后批量管理(下载、升级等)依赖包(源码)。dep 是一个开源项目, 大家可以在 https://github.com/golang/dep 了解详细信息，其安装方式大家可以参考官方说明，这里我们主要介绍其使用。

基本操作

通过 dep init 命令来初始化，会创建Gopkg.lock,Gopkg.toml文件和一个空的vendor目录。

我们在代码中通过 import 命令添加依赖后，通过 dep ensure 就可以下载依赖到本地 $GOPATH/src 目录下。

main.go

Gopkg.lock

通过 dep status 我们可以查看当前依赖引用的情况

另外有一个 dep check 命令来检查是否存在依赖被引用，但是代码中并没有使用的情况，Go 语言对于依赖的引用比较严格，不允许引用了但是没使用的情况。从软件安全的角度考虑，这是一个很好的实践，避免引入一些安全风险。

当然，这种时候我们就需要移除本地依赖，最好不要手动删除vendor中的内容，而是通过 dep ensure -update 命令来移除。

从 dep 的目录结构，我们可以分析出 dep 的基本工作思路:

这里面有两个关键的步骤:

解析依赖

从当前项目的 import 文件中解析出整个工程的依赖情况，并结合 Gopkg.toml 定义的规则，然后将依赖关系输出给 Gopkg.lock，注意这个 lock 文件最好不要手动修改。

获取依赖

通过 Gopkg.lock 了解整个依赖关系之后，将依赖的具体内容拉取下来放到 vendor 目录中，然后执行 Go build 时从本地的 vendor 读取依赖并完成构建。

这一些都是在 dep ensure 时完成的，其实在执行这个命令时还可以传参数，最主要的是 -no-vendor 和 -vendor-only 这两个参数。

-no-vendor 参数只会导致运行 resolve 函数，结果是创建一个新的Gopkg.lock 文件，不会更新 vendor；而 -vendor-only 参数将跳过 resolve 并仅运行 vendoring 函数，导致 vendor/ 从已存在的Gopkg.lock 重新更新。

关于 dep 更多深入内容，可以参考

https://golang.github.io/dep/docs/introduction.html

总结

Go dep 目前是一款比较好用的依赖管理工具,很多比较大型的项目都在使用，从中可以学习到依赖管理的一些基本思路，对于理解其他语言，比如 NPM 的依赖管理模型也是比较有好处的。

更多精彩内容可以专注我们的在线课堂

微信搜索公众号：jfrogchina 获取课程通知

灰度发布是一种常见的服务滚动升级或 A/B 测试策略。在新版本服务正式发布前，可以部署少量的新版本服务和上个版本共存，用部分生产流量测试新版本的功能和特性。如果新版本反馈良好，则可以渐进地提高新版本的比例或者全部替换成新版本，如果有问题也能够及时撤回，不至于造成太大范围的影响。

目前，原生容器发布基本都是使用 deployment，通过给 deployment 和 service 灵活配置 labels ，可以实现一种基于服务版本的灰度发布。

由于原生 Ingress 对象描述能力的限制，一些常见 Ingress controller 的灰度发布功能也大打折扣，很难满足用户灰度发布的实际需求。

 

博云基于原生Ingress，做了大量增强，基于请求特征的灰度发布是其中一个重要特性。

 

使用 deployment 实施灰度发布

 

通过配置 pod labels 和 service label selector，Kubernetes 原生支持灰度发布。假设我们部署了 echo-demo 服务的两个版本的 deployment：

> echo-demo-v1.yaml

name: echo-demo-v1

replicas: 3

…

labels:

app: echo-demo

track: stable

…

image: deploy.bocloud/ingress/echo-demo:1.0.0

> echo-demo-v2.yaml

name: echo-demo-v2

replicas: 2

…

labels:

app: echo-demo

track: canary

…

image: deploy.bocloud/ingress/echo-demo:2.0.0

 

以及一个 echo-demo service：

 apiVersion: v1

kind: Service

metadata:

name: echo-demo

spec:

ports:

– port: 80

protocol: TCP

targetPort: 8080

selector:

app: echo-demo

 

上述配置中，echo-demo service 聚合了 echo-demo-v1 和 echo-demo-v2 两个版本的服务，两个版本分别有 3 个和 2 个实例。此时我们访问 echo-demo service，请求将根据实例数量的占比按 3:2 的比例分布到 v1 和 v2 两个服务中。这样就实现了基于权重的灰度发布。

 

然而这种灰度发布却自有其限制和问题。首先，如果我们给服务加上自动水平伸缩（HPA），那么两个版本的服务将完全根据各自的负载情况独立调整 pod 实例数量，这样一来两个版本的实例数量和比例就会发生变化，打破我们一开始设置的灰度比例。其次，如果我们只想配置很小比例的请求到灰度版本，比如 100:1，那么在最少提供一个灰度版本 pod 的前提下，需要配置最少 100 个旧版本实例，很不灵活。第三，除了按比例的灰度策略，有时可能还需要根据请求特征来辨别用户并分配灰度服务到其中的一小部分。由于deployment有着上述的缺陷，导致其很少被当做灰度使用的原因。所以在实际应用当中，灰度发布基本上 由ingress来做。而这几个问题，都可以通过使用 Ingress 灰度发布方案来解决。

 

Ingress 能描述灰度发布吗？

Ingress 是 Kubernetes 平台的一个原生 API，定义了 HTTP 路由到 Kubernetes service 的映射。Ingress Controller 依据 Ingress 对象的声明，动态生成负载均衡器的配置文件，由负载均衡器将 k8s 内部服务暴露出去，Nginx Ingress Controller 是使用最广泛的一个 Ingress 控制器。一个典型的 Ingress 描述文件如下：

 

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

name: echo-demo

labels:

app: echo-demo

annotations:

kubernetes.io/ingress.class: nginx

namespace: default

spec:

rules:

– host: test.domain.com

http:

paths:

– backend:

serviceName: echo-demo-v1

servicePort: 80

path: /echo

– backend:

serviceName: hello-world

servicePort: 8080

path: /hello

 

由 Ingress API 可以看到，一个域名下可以定义多个访问路径，然而一个路径却只能定义一个 service。于是，在使用 Ingress 对象来描述灰度发布的情形下，要实现一个访问端点与多个服务版本的映射，仍然只能采用上述一个 kubernetes service 聚合多个版本的 deployment 的方式，这种方案的种种问题上文已经分析过了。社区版 Nginx Ingress Controller 受限于 Ingress API 的描述能力，对灰度发布的支持完全是不可用的状态。有没有一种办法，既兼容 Ingress API，又能做到一个访问端点映射到多个 service 呢？

博云基于 Nginx Ingress Controller 开发的 Ingress 控制器 BeyondELB，设计了一种 Ingress 组合模型，在兼容 Ingress API 的基础上，用 labels 给 Ingress 对象分类，并将多个不同类别的 Ingress 对象组合成一个逻辑 Ingress，从而实现了一个访问端点到多个 service 的映射。这种组合模型为实现另一种灰度发布方案提供了可能。

 

使用 BeyondELB

实施基于权重的灰度发布

上面可以看到，使用 deployment labels 实现的基于权重的灰度发布，其灰度比例完全依赖于服务的实例数量，而引入 HPA 之后服务实例数量可能会发生倾斜从而打破灰度比例。而由 Ingress 组合模型实现的灰度方案中，一个访问端点能够配置多个 service，每个 service 有自己的灰度权重和同一版本的服务实例，灰度权重不再和服务实例数量相绑定。通过将灰度权重和服务实例数量解耦，权重可以随时按需调整，服务的实例数量则可以根据负载情况自行伸缩，不会影响到设定好的灰度比例。

采用了 Ingress 组合模型的 BeyondELB 支持上述权重灰度发布策略。可以为某个 Ingress 访问路径定义一个或多个服务版本，然后为不同服务版本设定灰度权重，请求将按照灰度权重分配到不同版本的服务中。

上图中，选择开启基于权重的灰度发布，定义了一个灰度服务并设定 20 的权重，如果主版本服务的权重设定为 80（图中未给出主服务版本定义），则请求将按照 4:1 的比例分配到主版本服务和灰度版本服务。下面对配置了 80/20 权重的服务连续请求 100 次，可见流量按设定的比例分配到 v1 和 v2 服务中。

 

$ for i in `seq 1 100`; do curl -s http://test.domain.com/weight; done | jq .version | sort | uniq -c

78 “1.0.0”

22 “2.0.0”

使用 BeyondELB

实施基于请求特征的版本级灰度发布

在某些场景下，可能会需要对灰度选择有更好的控制，比如对于 HTTP 服务来说，可以通过请求特征甄别用户，允许将具有特定请求 Header 或 Cookie 的用户发送到灰度版本。

 

上图中，我们添加了一个灰度服务版本，并且设定灰度策略为“基于请求特征”。当请求附有名为 “canary” 值为 “true” 的请求 Header 时，将由该灰度服务版本响应；而其它未匹配该灰度条件的请求则由主服务版本响应（图中未给出主服务版本定义）。

 

我们通过以下两个脚本测试基于 Header 的灰度效果。

 

请求携带名为 canary 且其值为 “true” 的 Header：

$ for i in `seq 1 100`; do curl -s -H “canary: true” http://test.domain.com/header; done | jq .version | sort | uniq -c

100 “1.0.0”

 

请求不携带名为 “canary” 的 Header：

 

        $ for i in `seq 1 100`; do curl -s http://test.domain.com/header; done | jq .version | sort | uniq -c

100 “2.0.0”

除了基于请求 Header 的灰度匹配策略，博云的 Ingress Controller 还支持基于请求 Cookie 的匹配策略，以及多个 Header 或 Cookie 灰度条件组合的匹配策略。我们还可以用正则表达式匹配 operator 来实现更具体化的灰度方案，比如如下匹配表达式可以将 User ID 以 3 结尾的用户发送到灰度服务版本。

 

(header(“x-userid” regex “^[0-9]+3$”)

 

总结

通过使用 Kubernetes pod labels 和 service，可以初步实现基于权重的灰度发布。但这种灰度发布依赖于服务版本的实例数量，不仅不灵活而且在引入 HPA 时会造成服务比例倾斜。博云自研的 Ingress Controller 将灰度权重和服务实例数量解耦，服务可依据负载和 HPA 规则自行伸缩实例，不影响灰度比例。而基于 Header 或 Cookie 的灰度匹配策略，为实现更可控的灰度方案提供了支持。除了增强的灰度发布能力，博云商用版本的 Ingress Controller 还支持租户级负载、热更新等特性，后续将会逐步介绍。

近日，中国通信标准化协会云计算标准和开源推进委员会（已下简称信通院）主办《OSCAR 开源先锋日——云原生专场》，由云原生开源产业联盟、CNCF基金会联合选出的2020年度云原生应用十大优秀案例重磅发布。谐云为中移在线服务有限公司（以下简称中移在线）搭建的容器云PaaS平台项目在众多头部企业实践案例的激烈角逐中脱颖而出，成功入选云原生十大优秀案例，并成为全球最大的客服专有云案例。

近几年，中国本土的云原生力量已得到长足发展，生态体系逐步完善，本土引领的云原生开源项目开始反哺国际社区。云原生应用范围也逐步由互联网向传统行业拓展，帮助传统企业构建“好用的架构”和“适用于云的应用”。云原生应用十大优秀案例的评选，旨在推广云原生应用在行业成功落地的实践经验，树立行业先锋典范。同时本次活动征集的十大优秀案例将入选首版中国云原生生态图景（landscape）。中移在线容器化PaaS项目以高资源弹性伸缩、高持续交付效率、大规模集群&容器实例、跨中心容器、技术/应用服务等创新等高效应用价值博得了评委的一致好评与认可。

入选理由

中移在线容器云PaaS 平台的创新价值主要体现在三个方面：

第一， 搭建了全球最大的客服专有云。实现了自主研发容器云在客服多场景中大规模应用，打造了开源自主、国产可控、技术领先的客服专有容器云，为其提供10亿级用户支撑能力。

第二， 降低IT 资源运行和集成成本，打造了高性能高效率高可靠环境。利用容器化带来的虚拟化能力替代原有虚拟机的资源隔离方式，节约大量的许可成本，实现资源层面的降本增效，并通过混合部署，结合业务负载自动弹性扩缩容，资源利用率提升至业内领先水平。

第三，建设容器化云服务环境，从整体提高开发、运维、管理的收益。利用容器云的标准化帮助开发效率提升70%，管理定责效率提升90%以上，同时通过建设高可靠高性能集群，为中间件容器化提供切实有效的运行基础，结合Operator组件，在中移在线生产环境实现了企业级的容器化中间件自助服务能力。

中移在线容器云PaaS 平台的落地，具有明显的示范意义。目前，谐云为中移在线容器云PaaS平台搭建已经到了第三期，实现了全量业务的容器化改造迁移和全面的技术升级。谐云作为中国数字基础设施建设云原生软件的领军企业，独自凭借着强大的底层核心技术实力和专业的服务交付能力，在大型企业中获得了广泛、成功的实践，为企业奠定了坚实的技术基石。

接下来，谐云也将一同继续参与信通院在云原生白皮书撰写等方面的工作，为云原生技术的应用落地和加速创新做出贡献！

https://v.qq.com/x/page/q0976bknoii.html

欢迎回到Portworx系列讲解视频。我是Ryan Wallner。今天我们来介绍如何配置Portworx存储集群。这里我们概要性的对Kubernetes和Portworx的结构进行介绍，如何在Kubernetes上配置Portworx集群，以及正确安装Portworx需要哪些命令和参数。这里我们有一组已经配置好的高可用的Kubernetesmaster节点，一组worker节点，在这些节点上我们来安装Portworx。

Portworx需要一些资源的支撑。每一个worker节点都需要有CPU，不论是本地裸金属，还是云端，至少需要4个核以上的CPU。根据工作负载的不同，也许会需要更多核的CPU，例如运行一组数据库，4个核就不够了。最少的情况下我们需要4个核。内存建议至少4G。

跟CPU的核数一样，内存越大计算能力越强。可以根据自身的成本预算和负载的内存需求情况，来配置合适的资源供Kubernetes使用。但是运行Portworx，就需要满足4核CPU和4G内存的最小要求。因为Portworx是一个持久存储和数据管理系统，因此需要磁盘和驱动做支撑。

磁盘需要至少8G，我们推荐128G。4个节点的话，8G显得有点少。如果每个节点有128G，就能够有一个不错容量的存储池，来支撑存储系统。目前来看，还很少有为节点配置1TB以上。还要看运行的应用和需要的情况来定。网络方面，我们推荐10G的内部网络互联。

存在一个管理网络和一个数据网络。你可以把数据aka的复制、和应用的存储IO分配到不同的网络上。一个数据网络会存在，我们标记为D，还会存在一个管理网络，我们标记为M。因此管理网络和数据网络都可以通过网络进行连接。这些使你可以把I/O和数据流量进行分配。我们接下来介绍一下如何配置，需要确保数据网络至少是10G互联的。管理网络可以稍微低一些。Portworx的端口，需要9001到9021，这个范围可以配置的，这是默认的配置范围。除非有其他的端口冲突，就不要改变这些端口范围，它们是默认的Portworx通讯的端口。

对于Kernel版本，你至少需要3.10为Linux操作系统的版本，因为我们使用了很多更新的Linux Kernel集成、工作流和数据流等功能。键值存储数据库，etcd是最常见的，以及HashiCorp的Consul也可以选用。是的，Kubernetes集群在Master节点上运行etcd，注意键值数据库完全是分开的。

我在这里标记一下etcd，它通过网络会被附加到Portworx上，并且是独立的。它保存集群信息，元数据这些。对于一些有一定规模的集群，比如20或者25个节点的Portworx，我们推荐外部数据库，键值存储数据库，因为它会把I/O和CPU的资源放在外部系统上以及保持它们在独立的错误域里。

好的方法是保持一个独立的错误域，并且在配置过程中保持存有备份和快照，这样出现问题的时候可以恢复etcd数据库。对Kubernetes etcd数据库也可以这样操作。我们来介绍这两种方式。一种方式是有一个build-in的键值存储，这意味着Portworx可以自动工作，不需要人工干预，可以自动进行快照，也可以备份和恢复，但这是在20~25个Portworx节点的情况。现在对于Portworx所需资源有了一个整体了解，我们在介绍如何来配置它。我首先需要来介绍一下-C option，我来展示一个例子，来看在Kubernetes部署中是什么样的，或者Portworx运行中的DaemonSet。这样从命令行和EMO的角度我们就能更好的理解。

 

-C是我们的集群名称，你可以有其他的命名，但是不要有重复。因为如果用同样的名字，在应用分布和在etcd中配置的过程中，可能会出现冲突。所以确保集群名称是不重复的，这非常重要。我们接下来介绍存储，我们数据存储的选项。这里有一些，我们来看一下，你至少需要配置一项来定义你的存储磁盘或者后端存储，可以是本地的8G或者128G的磁盘驱动器，或者是云端存储驱动，例如SAN附加存储。不论是什么情况，-S都需要被使用，来指向一个特定的磁盘驱动：dev/sdb。你可以列出它们的名称，或者通过一个卷模板来使用。现在我来连接到卷模板，这是在云中来使用的，我想要使用gb2，有200G的卷，这会被认为是一个模板。Portworx会自动的与云的API进行沟通、部署、并且附加到Portworx worker节点上。

-Z是一个零存储节点。使用的情况是，如果你想要Portworx节点来加入到Portworx集群，也就是说着它需要附加\mount卷、并且允许应用具备I/O和使用卷。但是它不会给存储集群贡献更多的存储，也就是说它也不需要有磁盘。所以这就是-Z，零存储节点。-A，可以提供我们需要的所有功能。如果Portworx需要查询来看到底有多少没有被mount的未被使用的磁盘驱动。你可以增加-F，表示可以强制使用任何有文件系统的磁盘驱动。

 

这些是典型的操作中使用的参数。我们再来介绍一下数据网络和管理网络。配置时为数据网络使用-D，为管理网络使用-M。eth0，eth1这些。另外还有一个比较重要的就是 -X，这是你的调度器。“请告诉我的Kubernetes调度器来做更多的工作”。

 

我们介绍了STORK，有一个单独的视频介绍STORK，它是Kubernetes的存储调度器，与Kubernetes的调度器紧密集成。键值存储，会是IP和端口。通常运行在2379端口。也许是负载均衡器的IP地址，或者是etcd数据库的虚拟IP地址。如果你不想要使用外部数据库，你就不能使用 -b。-b表示使用内部的etcd数据库，或者是键值存储数据库。Portworx会自动的用高可用方式部署键值。高可用键值存储在至少3个节点上，并且配置压缩存储。如果低于20/25个节点，你可能就想使用-b，因为不论你是否想保持对etcd集群的感知，或者对集群本身的感知，可以留给Portworx来自动完成。

还有一些其他的部分，如果你想要使用-b，你需要配置一个元数据标志，表示这些是专门为键值存储数据库发送元数据I/O使用的驱动，所以它与数据I/O是分开的磁盘。还有就是缓存设备，它允许你在这些节点上选择最快的驱动。如果这些Portworx节点中的某一个使用GB2卷，在服务器上有一个NVMe或者一个io1类型的磁盘，就会比普通的驱动要快很多。

你可以使用它作为缓存设备，被Portworx作为缓存来使用。总结一下这些重要的标签。- C是集群名称。-A可用来获取磁盘。-Z代表零存储节点。S代表确定的存储，意味着磁盘模板或者存储设备本身。-D表示数据网络。-M表示管理网络。-X代表调度器或者Swarm，或者Kubernetes。-K代表外部键值存储。-b代表内部键值存储数据库、缓存设备、或者配置缓存设备/缓存元数据，供内部键值存储使用。

另外还有一些，我在这里就不再详细叙述，我们有spec生成器，你可以通过central.portworx.com来访问。你使用spec生成器的时候，它会用图形界面指导你来选择使用这些参数。以上我们介绍了在配置Portworx存储集群中需要考虑的一些方面，希望对您有帮助。谢谢！

 

 

引言

从Go 1.13开始，Go Module作为Golang中的标准包管理器，在安装时自动启用，并附带一个默认的GOPROXY。

但是对于其他的GOPROXY选项，比如JFrog

GoCenter，以及你自己的Go Module包，你需要在公众视野中保持安全，你应该选择什么样的配置? 你怎样才能不让你的公共和私人资源成为一个纠缠的结?

先让我们来看看GOPROXY是干什么的，以及如何为一个快速、可靠和安全的系统设置一个GOPROXY。

什么是GOPROXY?

GOPROXY控制Go Module下载的来源，有助于确保构建的确定性和安全性。（传送门：大家可以在JFrog公众号里搜索 Go Module， 前文介绍里Go Module 带来的收益以及如快速转型Go Module）

GOPROXY时代之前，在Golang开发时，模块依赖关系直接从VCS系统中的源存储库下载，如GitHub、Bitbucket、Bazaar、Mercurial或SVN。来自第三方的依赖项通常从公共源repos下载。私有依赖项必须在存储它们以下载模块源文件的VCS系统中进行身份验证。

虽然上面的工作流得到了广泛的应用，但是它缺乏确定性和安全性构建，以及开发过程的两个基本需求:不变性和可用性。模块可以被作者删除，也可以编辑修改当前被发布的版本。虽然这些场景被认为是不好的实践，但它们确实经常发生，如下图：

使用GOPROXY

为您的Golang开发或CI环境设置GOPROXY，将Go Module下载请求重定向到GOPROXY 指向的缓存库。

使用GOPROXY进行模块依赖关系的管理的有助于开发构建不变性需求。通过从GOPROXY的缓存中返回模块包，它能够为用户请求的某模块版本提供相同的返回（Go module模块代码），即使模块最近在VCS repo中被不正确地修改过，从而保证多次构建结果一致。

另外GOPROXY的缓存还有助于确保模块始终可用，即使VCS repo中的原始模块已被销毁。

使用GOPROXY有不同的方法，这取决于你想使用的go模块依赖的来源，通常有公共的GOPROXY，私有Go Module，以及私有的GOPROXY

公共GOPROXY

公共GOPROXY是一个集中式的存储库，全球各地的Golang开发者都可以使用它。它缓存了大量开源的Go模块，这些模块可以从第三方公开访问的VCS项目存储库中获得。大多数此类GOPROXY，比如JFrog GoCenter，Goproxy.cn都是免费提供给Golang开发者社区的。此类GOPROXY 的架构拓扑如下图，提供了Go Module 的一致性以及可用性能力：

要使用公共GOPROXY，将Golang环境变量设置为其URL:

$ export GOPROXY=https://gocenter.io

以上设置将所有模块下载请求重定向到GoCenter。从公共GOPROXY下载要比直接从VCS下载快得多。

除了完成下载之外，一个公共的GOPROXY还可以为GoLang开发者提供关于它所拥有的模块的更详细的信息。JFrog GoCenter提供了丰富的UI，支持搜索和访问模块的安全信息(如cve)、非安全元数据(如Star数量，下载统计数据以及License信息)和gosumdb支持。这些元数据有助于用户在选择开源Go模块时做出更好的决策。

私有Go Module

通常，GoLang项目会同时使用开源和私有模块。一些用户使用GOPRIVATE环境变量来指定一个必须绕过GOPROXY和GOSUMDB的路径列表，并直接从VCS repos下载私有模块。例如，您可能希望使用GoCenter检索所有开源模块，但只从公司的服务器请求私有模块。如下图：

要使用GoCenter公共GOPROXY和私有模块，请设置Golang环境变量:

$ export GOPROXY=https://gocenter.io,direct

$ export GOPRIVATE=*.internal.mycompany.com

这种对GOPRIVATE的使用也确保了你对这些私有模块的使用不会因为请求到一个开放网络上的公共GOPROXY &

checksum数据库服务器而“泄露”。另一种替代方法是使用GONOSUMDB变量，该变量包含对私有go模块的引用。虽然这种配置使Go客户端能够同时解析公共模块和私有模块依赖，但它并不强制私有模块的不可变性或可用性要求。

私有GOPROXY

私有GOPROXY是一种在您自己的基础设施上存储公共和私有Go模块的工具。

公共模块通过在二进制存储库管理器(如JFrog

Artifactory)中代理一个公共GOPROXY缓存到企业内部网络。

私有模块也可以从VCS repos缓存到改存储库中。通过这种方式，可以保证公共和私有Go模块的不变性和可用性。

在Artifactory中，您可以通过设置GoCenter的远程存储库（remote reposiroty），以及指向私有GitHub 仓库(用于私有模块)的远程Go模块存储库，以及本地Go模块存储库，将上述三个仓库组合到一个虚拟存储库中，作为用户统一单元进行访问，如下图:

在Artifactory中设置名为“go”的虚拟存储库的GOPROXY:

$ export GOPROXY=”https://:@my.artifactory.server/artifactory/api/go/go

$ export GONOSUMDB=”github.com/mycompany/*,github.com/mypersonal/*”

因为您的私有VCS repos中的模块在sum.golang.org的公共校验和数据库中没有条目，所以它们必须被排除在go客户端的检查之外。将GONOSUMDB设置为您的私有VCS repos可以实现这一点，并将防止这些私有模块的go get命令由于校验和不匹配而失败。

在这个配置中，您可以确保对私有模块的引用不会“泄漏”，同时还确保了公共模块和私有模块的不可变性和可用性。

总结：打破断结

正如您所看到的，使用私有GOPROXY提供了最确定、最可靠和最安全的功能。

您还可以通过您的私有GOPROXY到您的构建工具的网络接近度来加速模块依赖关系的解析。JFrog Artifactory可以安装在您最需要它的地方:本地数据中心部署或云中，或公共云提供商的SaaS版本。

这些好处不仅仅局限于Golang开发。大多数技术公司使用不止一种语言和多个包管理器。例如，如果代码是用Golang编写的，那么npm可能用于UI,

Docker可能用于分发交付，Helm可能用于在k8上部署应用程序。

通过支持超过27种包类型，Artifactory可以为所有应用程序提供确定性、稳定和安全的软件开发过程。

更多精彩内容可以专注我们的在线课堂

微信搜索公众号：jfrogchina 获取课程通知