【docker容器技术】Linux容器架构

Daniel_Ji阅读(830)评论(0)

1、整体架构

在 Linux 环境中,docker的整体架构

容器管理工具(例如 Docker)是基于一组更精细的容器工具构建的: runccontainerd

Linux 上的 Docker 体系结构Linux 上的 Docker 体系结构

1.1 操作系统(底层技术)

1.1.1 Control Groups:对资源分配和限制

cgroup将限制应用程序使用一组特定的资源。cgroup允许Docker引擎将可用的硬件资源共享给容器,并有选择地实施限制和约束。例如,可以限制特定容器可用的内存。Cgroups 是Linux 内核提供的一种机制,这种机制可以根据需求把一系列系统任务及其子任务整合(或分割)到按资源划分等级的不同组内,从而为系统资源管理提供一个统一的框架。

Cgroups可以限制、记录任务组使用的物理资源(cpu、memory 、io等),主要作用如下:

  • 资源限制:对任务使用的资源总额进行限制
  • 优先级分配:控制任务运行的优先级
  • 资源统计:统计系统资源的使用量
  • 任务控制:对任务执行挂起、恢复等操作

1.1.2 Namespace:对系统资源的封装隔离

Docker使用namespace技术为容器提供隔离,在运行容器时,Docker将会为其创建一个namespace集合。这些namespace为容器提供隔离层,容器的每个方面都在单独的namespace中运行,并且其访问仅限于该namespace。

Namespace是对全局系统资源的一种封装隔离,使得处于不同namespace的进程拥有独立的全局系统资源,改变一个namespace中的系统资源只会影响当前namespace里的进程,对其他namespace

中的进程没有影响。而Docker其实就通过 Linux 的Namespaces对不同的容器实现了资源隔离。

在Linux内核中提供了多种namesapce隔离系统调用,如下所示:

  • pid: 进程隔离(PID: Process ID).
  • net: 隔离网络接 (NET: Networking).
  • ipc: 隔离IPC资源访问 (IPC: InterProcess Communication).
  • mnt: 隔离文件系统挂接点 (MNT: Mount).
  • uts: 隔离内核和版本标识 (UTS: Unix Timesharing System).

1.1.3 Layer Capabilities:

联合文件系统或UnionFS是通过创建层进行操作的文件系统,使其非常轻便且快速。Docker引擎使用UnionFS为容器提供构建模块。Docker引擎可以使用多个UnionFS变体,包括AUFS,btrfs,vfs、overlay、overlay2、zfs、brtfs和DeviceMapper等。

2 控制器

1.2.1 runc:

是一种 Linux 命令行工具,用于根据OCI 容器运行时规范创建和运行容器。runc是容器标准化的产物,为了避免docker垄断容器标准,成立了opencontainers组织,定义了容器,镜像和仓库的标准,runc就是该标准的一个实现,通过runc可以完成容器的启停等操作。

1.2.2 containerd shim

一个容器的启动就是一个进程的启动,而containerd-shim就是容器所在的进程。容器运行的真正载体,一个容器对应一个containerd-shim进程。容器运行时通过调用oci的一个标准实现runc来完成对应容器的启停过程,但是容器的管理都托管于容器的shim进程。

shim主要是作为容器进程的父进程,与containerd解耦,可以实现containerd挂掉的时候容器依然运行;shim的设计允许runc执行后即可退出,runc非常驻内存操作。另外shim用于收集容器状态以及向containerd报告容器状态。shim设计的第二个目的,主要是避免runc运行占用过多的内存,go语言默认的是静态编译,如果一个机器上运行N个容器,就需要占用N*runc消耗内存,shim可以减缓,但是不能完全消除。至于runc为何不使用动态编译的原因,猜测是为了尽可能减少部署的麻烦。

1.2.3 containerd:

containerd是一个守护程序,它管理容器生命周期,从下载容器到容器映像并将其解压缩到容器执行和监督。然而containerd并不直接做此事,而是交给runC来运行container。而Docker Engine则依然需要负责管理image,至于image的运行(container)则交给containerd组件来完成。docker engine的守护进程,接收docker client的请求,完成镜像、容器、容器网络、容器存储、swarm集群的管理。其中容器的管理通过rpc调用containerd进行管理。

containerd是一个工业级别的容器运行时,强调简单,健壮和可移植。它宿主机上容器的完成声明周期,主要提供如下功能:镜像的传输和存储,容器的运行和管理,底层的存储和网络等。containerd被设计成可以集成进入大型系统中,而不是直接被开发或者终端用户使用的。从containerd可以单独作为k8s的容器运行时即可看出。在docker内,实现了dockerd和cotainerd的解耦,可以容器不停,完成dockerd升级操作。需要docker的live-restore配置支持。

4 容器引擎

Docker Engine Components FlowDocker Engine Components Flow

在架构中,Docker Engine是客户端-服务器模式的应用程序:

  • 守护程序:服务器是在宿主机中长期运行的程序,作为容器的守护程序( dockerd 命令)。
  • API接口:REST API,它指定程序可以用来与守护程序进行通信并指示其操作的接口。
  • 客户端:命令行界面(CLI)客户端(docker 命令)。

CLI使用Docker REST API通过脚本或直接CLI命令控制或与Docker守护程序交互。许多其他Docker应用程序都使用基础API和CLI。守护程序负责创建和管理Docker 对象,例如镜像,容器,网络和数据卷。

4.1 libcontainer

Docker引擎将名称空间,控制组和UnionFS组合到一个称为容器格式的封装器中。默认的容器格式为libcontainer。Libcontainer 是Docker中用于容器管理的包,它基于Go语言实现,通过管理namespaces、cgroups、capabilities以及文件系统来进行容器控制。可以使用Libcontainer创建容器,并对容器进行生命周期管理。

4.2 libnetwork

Libnetwork是Docker团队将Docker的网络功能从Docker核心代码中分离出去,形成一个单独的库。 Libnetwork通过插件的形式为Docker提供网络功能。 使得用户可以根据自己的需求实现自己的Driver来提供不同的网络功能。

官方目前计划实现以下Driver:

  1.  Bridge : 这个Driver就是Docker现有网络Bridge模式的实现。
  2.  Null : Driver的空实现,类似于Docker 容器的None模式。
  3.  Overlay : 隧道模式实现多主机通信的方案。

“Libnetwork所要实现的网络模型(网络拓扑结构)基本是这样的: 用户可以创建一个或多个网络(一个网络就是一个网桥或者一个VLAN ),一个容器可以加入一个或多个网络。 同一个网络中容器可以通信,不同网络中的容器隔离。”我觉得这才是将网络从docker分离出去的真正含义,即在创建容器之前,我们可以先创建网络(即创建容器与创建网络是分开的),然后决定让容器加入哪个网络。

4.3 graph

graph driver主要用于管理和维护镜像,包括把镜像从仓库下载下来,到运行时把镜像挂载起来可以被容器访问等,都是graph driver做的。

4.4 plugins

Docker插件是增强Docker引擎功能的进程外扩展。这就表示,插件不会运行在Docker daemon中。你可以随时随地(如果需要可以在另一台主机上)启动你的插件。只需要通过Plugin Discovery通知Docker daemon这儿有一个新的插件可用即可。

4.5 REST Interface

REST API指定程序可以用来与守护程序进行通信并指示其操作的接口。

  • Registry API:提供了与来存储Docker镜像的Docker Registry集成的功能。
  • Docker Hub API:提供了与Docker HUB集成的功能
  • Docker Remote API:提供与Docker守护进程进行集成的功能

作者简介:季向远,本文版权归原作者所有。微博:ik8s​​​​

【prometheus性能监控】Mysql性能监控(mysqld_exporter)

Daniel_Ji阅读(1808)评论(0)

​​1、安装和配置mysql_exporter

1.1 使用docker安装mysql_exporter

在mysql数据中创建exporter用户,并给予此用户相关权限。为exporter用户设置最大连接数为3,以避免由于监控造成服务器过载。


CREATE USER ‘exporter’@’localhost’ IDENTIFIED BY ‘XXXXXXXX’ WITH MAX_USER_CONNECTIONS 3;

GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO ‘exporter’@’localhost’;


这里以容器的方式提供mysql_exporter,所使用的镜像为prom/mysqld-exporter,以守护进程方式运行此容器。对外暴露9104端口,通过DATA_SOURCE_NAME环境变量指定要监控的mysql数据库。


docker run -d -p 9104:9104 -e DATA_SOURCE_NAME=”user:password@(my-mysql-network:3306)/” prom/mysqld-exporter


1.2 查看mysql的指标数据

2、Prometheus监控

2.1 配置Prometheus

在Prometheus的配置文件(Prometheus.yaml)中,添加红色字体部分的内容。

​​

2.2 配置验证

在浏览器的地址栏访问http://{prometheus}/targets,将会看到新配置的mysql。

3 Grafana监控

3.1 配置mysql监控dashboard

下载mysql_exporter的dashboard(mysql-overview_rev5.json),在grafana中导入dashboard:mysql-overview_rev5.json。

参考材料:

​​​​​1)

作者简介:

季向远。本文版权归原作者所有。微博:ik8s

内建质量,你真的了解么?

JFrogchina阅读(605)评论(0)

 

内建质量定义

内建质量作用在开发过程中,要求软件生命周期之间参与的各个角色都需要实时的对软件的质量负责。确保软件在交付到下一环节前已经有了基础的质量保证。其核心目的就是减少因为质量问题导致的返工,而浪费大量人力成本。

1.敏捷中的内建质量

内建质量是规模化敏捷SAFe的核心价值观,引用下面一段话,我们看一下敏捷中定义的内建质量在讲什么内容(原文出处:https://www.scaledagileframework.com/built-in-quality/

简单的翻译过来就是,产品一旦被发布之后就有了好坏之分,通过某些检验方式已经无法提高或保证它的质量,所以质量检验必须内置在产品或服务构建的过程中,而不能在它发布之后。

2.DevOps中的内建质量

DevOps三步工作法中,第二步就是反馈原则,其中很重要的一个实践就是在源头保障质量,这里主要是指开发部门、测试部门。而在源头保障质量的通俗说法更像是“谁污染谁治理”。 DevOps倡导所有新的功能特性可以像流动的水一样,迭代到用户的终端,而水是不能逆流的,为了保证水流的质量,我们就必须在水流动的途中治理,直到最终交付到用户的手中。这也就是DevOps建设中一个新的理念“liquid software”

内建质量实践

1. 左移

左移是内建质量最好的实践,把质量问题从源头开始进行检查。

由开发侧发起的单元测试就是最典型的测试左移的案例,虽然高单元测试覆盖率需要投入大量的成本,但是对于某些行业,如金融行业,这个实践是必要的。另外测试左移不止是对代码来讲的,同样在需求评审阶段,就要对需求质量进行评估,推广到市场后是否真的能实现其价值.

随着DevSecOps的兴起,安全左移的重要性也体现出来。我们经历过很多次类似的情况,每当我们把经过了开发测试的软件发布到生产线上,经常会被安全部门或者第三方监管单位找麻烦,归根结底还是因为在开发过程中引入了某些不安全的开源组件,写了有风险的代码,而这些问题可能都是开发人员技术能力之外的。试想一下,如果在开发人员的IDE中直接提示开发代码的安全问题,引用组件的安全问题,并引导开发人员去解决的话,是不是相当于在开发的源头解决了安全问题呢,不但提高了软件的整体安全质量,同样也节省了效能。

2. 门禁

为了贯彻内建质量是否在开发体系中落实,我们需要设置一些质量度量标准,所以在软件生命周期的每个阶段设置质量门禁这种实践孕育而生,在代码提交或集成时,校验单元测试的覆盖率和通过率,检验代码的合规性,验证引用的组件安全性都是质量门禁的实践。如果没有通过质量门禁,说明内建质量没有达到标准,上线后由于质量问题返工的可能性会增加。下述门禁是需要被关注的:

代码质量

单元测试覆盖率

单元测试通过率

测试通过率

基础设施

代码安全性

第三方组件安全性

开源协议扫描

等…

内建质量落地

很多DevOps的建设场景中,最终落地的依旧是工具链,工具链是打通从开发到运维基础。为了保障内建质量的建立,两个方面的工具链是不可缺少的,下面罗列了一些常用的工具,如果大家准备在软件生命周期中增加内建质量的建设,可以参考下述工具

1. 专项工具类,解决特定质量检查场景:

源码质量:SonarQube、checkmarx、fortify

单元测试:Junit

自动化测试:selenium、postman、yapi

性能测试:jmeter

安全:Xray、Dependance-check

2. 集成工具类,打通工具链流程,统一展示:

集成工具:Jenkins、TFS、GitlabCI、tekton、

制品管理工具:Artifactory

总结

内建质量是精益、敏捷以及DevOps的核心原则之一,有助于避免与需求召回、返工及缺陷修复有关的延迟成本。所以内建质量,势在必行。

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

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

Portworx Essentials + Velero:备份Kubernetes应用

Portworx阅读(1134)评论(0)

Portworx近期发布了免费的Essentials版本。(https://portworx.com/announcing-portworx-essentials/)。Essentias)。

Essentials版本支持小规模Kubernetes生产系统运行所需的必要功能:也许是CICD的pipeline,或是处于开发早期的面向用户的APP。不论是那种应用,都需要更快的存储、高可用、加密、快照等等必要功能。PortworxEssentials提供了这些必要功能。

备份和恢复Kubernetes集群和所有应用,或仅备份和恢复一个独立的Kubernetes应用,包括数据、应用配置和Kubernetes对象(如CRDs、Secrets、服务账户等),具体应该怎么做呢?

Portworx Enterprise版本的客户可以使用PX-Backup,来完成一个端到端的备份和恢复解决方案。但如果用户正在使用Portworx Essentials,则需要用户把Portworx快照与开源Kubernetes备份方案Velero配合来使用。Velero可以备份Kubernetes状态比如应用配置、和存储在etcd的对象。这个方案很适初始小型规模的Kubernetes环境。当用户的Kubernetes环境规模扩大以后,可以转向使用Portworx Enterprise和PX-Backup。

接下来我们会介绍如何使用Portworx Essentials和Velero,通过Portworx快照来完成备份和恢复功能。

安装Portworx Essentials

你可以登录Portworx网站来获取免费的Portworx Essentials(https://ask.portworx.com/essentials/?utm_medium=website&utm_source=pricing%20page&utm_campaign=Essentials)。

Portworx微信公众号上一期的文章,专门介绍了如何安装和使用Portworx Essentials,可供您参考。

在AWS上使用S3来安装Velero Server组件

为了配合使用Velero和Portworx,用户必须安装服务组件以及对象存储。在下面的操作中,我们使用的是Amazon的S3,建立S3的操作步骤可以参考这里(https://github.com/vmware-tanzu/velero-plugin-for-aws#create-s3-bucket)。

注意:我们在本文中使用S3作为我们备份中需要的对象存储。也可以使用其他的对象存储,比如Minio、微软Azure、GCP,等,只要能够正确的配置即可。

一旦配置完成了Amazon S3,你可以通过下面的命令来安装Velero,首先安装Velero,安装完成后我们会增加Portworx的插件。

$ velero install \
--provider aws \
--plugins velero/velero-plugin-for-aws:v1.0.1 \
--bucket $BUCKET \
--backup-location-config region=$REGION \
--snapshot-location-config region=$REGION \
--secret-file ./credentials-velero

接下来,因为我们需要使用Portworx来完成云中的PV的快照,我们可以使用下面的命令来添加Portworx插件。

$ velero plugin add portworx/velero-plugin:1.0.0

一旦以上的步骤都顺利完成,就可以继续进行下面的配置了。

增加Portworx云身份验证

Portworx会创建基于云中块存储的快照(https://docs.portworx.com/reference/cli/cloud-snaps/)来备份用户的数据。因此,我们需要为Portworx配置对象存储的云身份验证。我们使用Pxctl – Portworx的CLI工具,来进行操作。首先,通过一个Portworx Pod创建PX-POD环境。

PX_POD=$(kubectl get pods -l name=portworx -n kube-system -o jsonpath='{.items[0].metadata.name}')

接下来,我们要确保我们的云快照是被加密的,这样我们可以创建一个Secret,并用这个Secret作为我们的加密密文,传递给Portworx。一个简单的方式是使用64位的哈希字符串。

echo "mysupersecret" | base64
bXlzdXBlcnNlY3JldAo=

接下来,我们通过pxctl,并基于Amazon的密钥和加密密文来创建我们的身份验证。

$kubectl exec $PX_POD -n kube-system -- /opt/pwx/bin/pxctl credentials create --s3-access-key  --s3-secret-key  --s3-region us-east-1 --encryption-passphrase bXlzdXBlcnNlY3JldAo= --s3-endpoint s3.amazonaws.com --provider s3 awss3
Credentials created successfully, UUID:f8d2cf6d-ab50-4e42-90b6-9930336ad898

为Portworx创建快照的位置

Velero可以为持久卷的数据和应用元数据使用SnapshotLocation(https://velero.io/docs/master/api-types/volumesnapshotlocation/)和BackupLocation(https://velero.io/docs/master/locations/)。可以使用下面的命令。

注意:你将会需要使用credId,它是一个从上文的你的pxctl 验证身份创建命令里产生的UUID。

$ velero snapshot-location create portworx-cloud --provider portworx.io/portworx --config type=cloud,credId=f8d2cf6d-ab50-4e42-90b6-9930336ad898
Snapshot volume location "portworx-cloud" configured successfully.

你可以通过使用Kubectl命令,来检查卷快照的位置,

$ kubectl get volumesnapshotlocation -n velero
NAME AGE
default 17m
portworx-cloud 30s

创建一个应用(比如WordPress)

现在我们来使用PortworxEssentials和Velero。我们需要一个应用,填入一些数据,然后做备份操作。你可以使用WordPress+MySQL应用,部署到一个名为WordPress的命名空间里。(https://github.com/wallnerryan/pwx-app-catalog/tree/master/apps/Blog/Wordpress)

注意:可以通过上面的链接,查看如何部署WordPress和Mysql的操作。

$ kubectl get po -n wordpress
NAME READY STATUS RESTARTS AGE
pod/wordpress-79c6db4c56-4sjjs 1/1 Running 0 72m
pod/wordpress-79c6db4c56-697rt 1/1 Running 0 72m
pod/wordpress-79c6db4c56-92whn 1/1 Running 0 72m
pod/wordpress-mysql-d8f757c9d-sknz8 1/1 Running 0 76m

你可以看见两个Portworx卷,分别备份了WordPress和MySQL。其中一个卷是由多个WordPress Pods共享的RWX,另一个是为单独MySQL数据库后端独享的RWO。

$ kubectl get pvc -n wordpress
NAME STATUS VOLUME STORAGECLASS AGE
mysql-pvc-1 Bound pvc-45837d2c... portworx-sc-repl3 72m
wp-pv-claim Bound pvc-cb520f93... portworx-sc-repl3-shared 72m

通过访问WordPress的服务端点,并且按照提示来创建第一篇文章作为应用的数据。可以通过kubectl get svc -n wordpress 命令来获取端点的信息。默认状态下,这个应用可以被NodePort访问。(https://kubernetes.io/docs/concepts/services-networking/service/#nodeport)

使用Portworx和Velero来完成MySQL+Wordpress的备份

现在我们在应用中已经创建了一些数据,让我们接着来备份一下应用和持久卷。

注意:–wait是可选的。

$ velero backup create wordpress-backup --include-namespaces=wordpress --snapshot-volumes --volume-snapshot-locations portworx-cloud --wait
Backup request "wordpress-backup" submitted successfully.
Waiting for backup to complete. You may safely press ctrl-c to stop waiting - your backup will continue in the background.
...............................................
Backup completed with status: Completed. You may check for more information using the commands `velero backup describe wordpress-backup` and `velero backup logs wordpress-backup`.

赞!我们已经使用Portworx和Velero成功创建了应用和数据的备份。

注意:Portworx Essentials的功能和限制(https://docs.portworx.com/concepts/portworx-essentials/),只允许每天每个卷备份一个云快照。同一天创建第二个备份会失败。我们可以等到第二天再创建备份,或者如果我们需要更频繁的备份的话,可以使用PX-Backup(https://portworx.com/cloud-native-application-backups-using-px-backup/)。

从备份中恢复MySQL和WordPress

为了模拟系统错误的出现,我们可以删除整个WordPress命名空间。

$ kubectl delete namespace wordpres

这样我们的WordPress和MySQL的部署就完全消失了,以及我们的PVs和PVCs也消失了。不用担心,我们从备份中来恢复。

$ velero restore create --from-backup wordpress-backup
Restore request "wordpress-backup-20200422153128" submitted successfully.
Run `velero restore describe wordpress-backup-20200422153128` or `velero restore logs wordpress-backup-20200422153128` for more details.

恢复操作完成后,你就可以重新访问你的NodePort端点了,你所有的数据也都恢复了。

注意:恢复操作中还有其他的选项,比如恢复一个新的命名空间。可以参考这里的文档。(https://velero.io/docs/master/restore-reference/)。

 

希望这篇文章能够帮助您更好的在小规模Kubernetes生产系统里管理有状态应用!

【docker容器技术】docker守护进程运行配置

Daniel_Ji阅读(1092)评论(0)

1、配置docker daemon

对于docker daemon,提供了两种配置方式:

  • 使用daemon.json配置文件,这是首选的方式。
  • 在使用dockerd启动时,通过flag设置。

当不能同时使用这两种方式进行相同选项的设置,否则会导致docker daemon无法启动。如果宿主机是linux,配置文件daemon.json的目录是/etc/docker/;

如果是宿主机是windows,配置文件daemon.json文件所在的目录是C:\ProgramData\docker\config\。

下面是配置文件的示例:


{

“debug”: true,

“hosts”: [“tcp://192.168.59.3:2376”]

}


通过此配置,Docker守护程序将以调试模式运行,通过2376端口侦听路由来自于192.168.59.3的流量。也可以通过手动启动Docker守护程序,并使用flag对其进行配置。下面是通过手动启动Docker守护程序进行配置的示例:


dockerd –debug  –host tcp://192.168.59.3:2376


2、Docker daemon目录

Docker守护程序将所有的数据保存在宿主机的一个目录中,这些数据包括:容器,镜像,卷,服务定义和机密等。默认情况下,此目录为:

  • Windows操作系统:/var/lib/docker
  • Linux操作系统:C:\ProgramData\docker

对于docker daemon目录,可以使用data-root配置选项设置为使用其他目录 。由于Docker守护程序的状态保留在此目录中,因此需要确保守护程序使用的是专用目录。如果两个守护程序共享同一目录(例如,NFS共享),则将遇到难以解决的错误。

3、Docker daemon配置选项

3.1 Linux操作系统

在Linux操作上,docker守护进程配置文件的默认位置是/etc/docker/daemon.json。可以通过–config-file标志指定非默认位置。下面是Linux操作系统上允许的配置选项完整示例:

{

“authorization-plugins”: [],

“data-root”: “”,  # docker的根目录 (默认值: “/var/lib/docker”)

“dns”: [],

“dns-opts”: [],

“dns-search”: [],

“exec-opts”: [],

“exec-root”: “”,

“experimental”: false,

“features”: {},

storage-driver“: “”,  # docker的使用的存储驱动,默认为bridge

“storage-opts”: [],

“labels”: [],

“live-restore”: true,

log-driver“: “json-file”,  # docker的日志驱动,此处的值为json-file

“log-opts”: {  # docker的日志设置

“max-size”: “10m”,  # docker的日志大小为10m

“max-file”:”5″, # 最大保留5个日志文件

“labels”: “somelabel”,

“env”: “os,customer”

},

“mtu”: 0,

“pidfile”: “”,

“cluster-store”: “”,

“cluster-store-opts”: {},

“cluster-advertise”: “”,

“max-concurrent-downloads”: 3,

“max-concurrent-uploads”: 5,

“default-shm-size”: “64M”,

“shutdown-timeout”: 15,

“debug”: true,

“hosts”: [],

“log-level”: “”,  # 设置日志层次 (“debug”|”info”|”warn”|”error”|”fatal”) (默认值为: “info”)

“tls”: true,

“tlsverify”: true,

“tlscacert”: “”,

“tlscert”: “”,

“tlskey”: “”,

“swarm-default-advertise-addr”: “”,

“api-cors-header”: “”,

“selinux-enabled”: false,

“userns-remap”: “”,

“group”: “”,

“cgroup-parent”: “”,

“default-ulimits”: {

“nofile”: {

“Name”: “nofile”,

“Hard”: 64000,

“Soft”: 64000

}

},

“init”: false,

“init-path”: “/usr/libexec/docker-init”,

“ipv6”: false,  # 是否启用ipv6网络

“iptables”: false, # 是否启用iptables规则,默认值为true

“ip-forward”: false,

“ip-masq”: false,

“userland-proxy”: false,

“userland-proxy-path”: “/usr/libexec/docker-proxy”,

“ip”: “0.0.0.0”,

“bridge”: “”,

“bip”: “”,

“fixed-cidr”: “”,

“fixed-cidr-v6”: “”,

“default-gateway”: “”,

“default-gateway-v6”: “”,

“icc”: false,

“raw-logs”: false,

“allow-nondistributable-artifacts”: [],

“registry-mirrors”: [], # 镜像仓库的镜像地址

“seccomp-profile”: “”,

“insecure-registries”: [], # 安全镜像仓库列表

“no-new-privileges”: false,

“default-runtime”: “runc”, # docker的默认运行时环境

“oom-score-adjust”: -500,

“node-generic-resources”: [“NVIDIA-GPU=UUID1”, “NVIDIA-GPU=UUID2”],

“runtimes”: {

“cc-runtime”: {

“path”: “/usr/bin/cc-runtime”

},

“custom”: {

“path”: “/usr/local/bin/my-runc-replacement”,

“runtimeArgs”: [

“–debug”

]

}

},

“default-address-pools”:[

{“base”:”172.80.0.0/16″,”size”:24},

{“base”:”172.90.0.0/16″,”size”:24}

]

}

在编辑daemon.json后,需要通过执行下面的命令对docker进行重启。


$ systemctl reload-daemon

$ systemctl restart docker ​


3.2 Windows操作

Windows上docker守护进程配置文件的默认位置是%programdata%\docker\config\daemon.json。可以通过–config-file标志指定非默认位置。Windows上允许的配置选项完整示例:

{

“authorization-plugins”: [],

“data-root”: “”,

“dns”: [],

“dns-opts”: [],

“dns-search”: [],

“exec-opts”: [],

“experimental”: false,

“features”:{},

“storage-driver”: “”,

“storage-opts”: [],

“labels”: [],

“log-driver”: “”,

“mtu”: 0,

“pidfile”: “”,

“cluster-store”: “”,

“cluster-advertise”: “”,

“max-concurrent-downloads”: 3,

“max-concurrent-uploads”: 5,

“shutdown-timeout”: 15,

“debug”: true,

“hosts”: [],

“log-level”: “”,

“tlsverify”: true,

“tlscacert”: “”,

“tlscert”: “”,

“tlskey”: “”,

“swarm-default-advertise-addr”: “”,

“group”: “”,

“default-ulimits”: {},

“bridge”: “”,

“fixed-cidr”: “”,

“raw-logs”: false,

“allow-nondistributable-artifacts”: [],

“registry-mirrors”: [],

“insecure-registries”: []

}

在编辑daemon.json后,需要通过执行下面的命令对docker进行重启。


$Restart-Service docker


 参考:

1)Windows 上的 Docker 引擎:https://docs.microsoft.com/zh-cn/virtualization/windowscontainers/manage-docker/configure-docker-daemon

2)dockerd:https://docs.docker.com/engine/reference/commandline/dockerd/


作者简介:

季向远,北京神舟航天软件技术有限公司。本文版权归原作者所有。微博:ik8s

Go 语言 2019 调查报告发布

alicloudnative阅读(550)评论(0)

424头图.jpg

对 Go 语言感兴趣但又不知从何学起的同学,可以参考一下 Go 语言系列文章:

Go 官方博客近日公布了 2019 年 Go 语言调查报告。本次调查收到的回复达到 10,975 份,约为去年的两倍。这些受访者的反馈意见将被选取用于改进 Go 语言的发展。

以下是 2019 年度的调查报告摘要:

  • 此调查中,受访者的受众特征与 Stack Overflow 的受访者相似,因此这些结果在某种程度上可以代表更广泛的 Go 开发人员;
  • 大多数受访者每天都要用到 Go 语言,并且该数字在逐年上升;
  • Go 的使用仍集中在技术公司,但它同时也被用于越来越多的行业,例如金融和媒体;
  • Go 最常见的用途仍然是编写 API/RPC 服务和 CLI 工具;
  • 模块在 Go 生态系统中的使用率很高,与此同时,围绕软件包管理的一些问题仍然存在;
  • 有待改进的重点领域包括 debug、模块和云服务的体验;
  • VS Code 和 GoLand  依然最受开发者欢迎,有 3/4 的受访者都喜欢它们。

有关调查报告的详细内容请继续往下阅读。

开发者背景

调查结果显示,在工作中使用 Go 语言的受访者比例与去年相当,均为 72%,这一数值几乎每年都在增长。在工作之余使用 Go 语言的人数比例则有所下降(70%→62%)。

1.png

从使用年限上来看,56% 的受访者使用 Go 语言进行开发的经验不足两年,相对来说算是新手。而有着较长时间 Go 开发经验的“老手”,多拥有 C/C++ 背景,对 JavaScript、TypeScript 和 PHP 则相对没有那么熟悉。另外,无论是 Go 的新手还是老手,大多数受访者最熟悉的语言还属 Python。

2.png

1. 使用 Go 的时长

3.png

2. 使用其他语言的经验

有意思的是,Go 是一个成功的开源项目,但大多数使用它的受访者却“很少”或“从不”为基于 Go 的开源项目做贡献。不过,随着 Go 社区的扩展,为它做贡献的受访者比例在缓慢上升中。

4.png

开发领域

在去年的调查中,多数受访者都集中在技术公司(包括软件、互联网等)。今年的受访者则来自更为广泛的开发领域。尤其是金融行业占比显著增加(8%→12%),来自技术行业的相对受访者比重从 52% 下降至 43%。

5.png

具体来讲,在 Go 的使用方面,最常见的领域是 Web 开发(66%)。在数据库相关领域使用 Go 的受访者数量显著增加,所占比例由去年的 29% 上升至 45%,排位也从第五跃升第二。其他常见领域还包括网络编程(42%)、系统编程(38%)和 DevOps(37%)。

6.png

Go 的主要用途依然是编写 API/RPC 服务和开发 CLI 应用程序,这两项分别占比 71% 和 62%。其次是库和框架方面,增长量巨大,所占比例从 30% 飙升至 48%。

7.png

开发环境

与往年一样,绝大多数被调查者表示在 Linux(66%)和 macOS(53%)系统上使用 Go。 这是本调查与 StackOverflow 调查存在很大差异的一个地方,后者有 45% 的受访者将 Windows 作为主要开发平台,而关于 Go 的调查中,这一数据只占 20%。

另外,受访者中有 38% 的人使用多操作系统应用这门跨平台语言,相较去年(41%)略有下降。

8.png

开发工具方面,VS Code、GoLand 和 Vim 仍占据编辑器排行榜前三位,并且这三位的使用份额占总数据的 3/4。其中 GoLand 的使用量在 2019 年增长最多(24%→34%),VS Code 的增长速度有所放缓。

9.png

今年的调查中新增了一个有关内部 Go 文档工具的问题。从总体数据来看,少数受访者(6%)表示所在的公司有运行自己的 Go 文档服务器。但如果仅查看大型组织(至少有 5,000 名员工)的数据,这一比例几乎翻了一番(11%)。

10.png

云开发

今年的问卷扩展了一些关于云开发的问题,可以看出,选择将 Go 应用部署到云上的开发者越来越多。其中,选择 AWS 的受访者数量(42%)几乎快要追上选择本地部署的受访者数量(44%)。

三大全球云提供商(Amazon Web Services、Google Cloud Platform 和 Microsoft Azure)的采用率均呈上升趋势,且牢牢占据绝大部分市场份额。

在满意度方面,受访者对在三大云提供商上使用 Go 感到总体满意。AWS 和 GCP 分别以 80% 和 78% 占有最高满意度,而 Azure 的满意度较低,为 57%。

11.png

对 Go 语言的态度

该问卷包含一个“你有多大可能将 Go 推荐给朋友或同事?”的问题,以此来计算净推荐值(Net Promoter Score, NPS)。最终 Go 在 2019 年调查中的净推荐值是 60 分(67% 的倡导者 – 7% 的贬低者),去年的调查中这一分数为 61 分。

12.png

长期被 Go 使用者诟病的包管理和缺少泛型这两个问题,依然是很多开发者使用 Go 时所面临的最大挑战。今年,提出工具存在问题的受访者比例也有所增加。Go 团队表示这些也是他们重点关注的领域,并表示希望在未来几个月中能够改善开发人员的体验,尤其是在模块、工具和入门经验方面。

13.png

Go 语言社区氛围

受访者对于 Go 社区的看法与往年相比有较大波动。认为自己在社区中有受到关注的人数比例从 82% 降至 75%。

另一方面,受访者对于这一问题的回应朝着两极分化的方向发展。选择“强烈同意”或“强烈反对”的比例都相对增加。Go 团队计划对此进行进一步研究。

14.png

以上就是 2019 年度关于 Go 语言调查的大致内容,完整调查报告还请查看 Go 官方博客

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”

Netflix如何使用Druid进行业务质量实时分析

JFrogchina阅读(506)评论(0)

 

一 Durid介绍

Apache Druid是一个高性能的实时分析数据库。它是为快速查询和摄取的工作流而设计的。Druid的优势在于即时数据可见性,即时查询,运营分析和处理高并发方面。

Druid不是关系数据库,需要的是数据源,而不是表。与关系数据库相同的是,这些是表示为列的数据的逻辑分组。与关系数据库不同的是没有连接的概念。因此,Netflix需要确保每个数据源中都包含Netflix要过滤或分组依据的任何列。数据源中主要有三类列-时间,维度和指标。

Druid的一切都取决于时间。每个数据源都有一个timestamp列,它是主要的分区机制。维度是可用于过滤,查询或分组依据的值。指标是可以汇总的值。

通过消除执行联接的能力,并假设数据由时间戳作为键,Druid可以对存储,分配和查询数据的方式进行一些优化,从而使Netflix能够将数据源扩展到数万亿行,并且仍然可以实现查询响应时间在十毫秒内。

为了达到这种级别的可伸缩性,Druid将存储的数据分为多个时间块。时间块的持续时间是可配置的。可以根据您的数据和用例选择适当的持续时间。

二 Netfilx遇到的问题

Netflix使用来自回放设备的实时日志作为事件源,Netflix可以得出测量值,以了解和量化用户设备如何无缝地处理浏览和回放。

一旦有了这些度量,就将它们输入数据库。每项措施均标有关于所用设备种类的匿名详细信息,例如,设备是智能电视,iPad还是Android手机。这使Netflix能够根据各个方面对设备进行分类并查看数据。反过来,这又使系统能够隔离仅影响特定人群的问题,例如应用程序的版本,特定类型的设备或特定国家/地区。以通过仪表板或临时查询立即使用此聚合数据进行查询。还会连续检查指标是否有警报信号,例如新版本是否正在影响某些用户或设备的播放或浏览。这些检查用于警告负责的团队,他们可以尽快解决该问题。

软件更新期间,Netflix为部分用户启用新版本,并使用这些实时指标来比较新版本与以前版本的性能。指标中的任何回归都会使Netflix发出中止更新的信号,并使那些将新版本恢复为先前版本的用户恢复原状。

由于该数据每秒可处理超过200万个事件,因此将其放入可以快速查询的数据库是非常艰巨的。Netflix需要足够的维数以使数据在隔离问题中很有用,因此,Netflix每天产生超过1150亿行。

三 Netfilx通过Durid处理海量数据分析

数据摄取

插入到该数据库是实时发生的。不是从数据集中插入单个记录,而是从Kafka流中读取事件(在Netflix的情况下为指标)。每个数据源使用1个主题。在Druid中,Netflix使用Kafka索引编制任务,该任务创建了多个在实时节点(中间管理者)之间分布的索引编制工作器。

这些索引器中的每一个都订阅该主题并从流中读取其事件共享。索引器根据摄入规范从事件消息中提取值,并将创建的行累积在内存中。一旦创建了行,就可以对其进行查询。到达索引器仍在填充一个段的时间块的查询将由索引器本身提供。由于索引编制任务实际上执行两项工作,即摄取和现场查询,因此及时将数据发送到“历史节点”以更优化的方式将查询工作分担给历史节点非常重要。

Druid可以在摄取数据时对其进行汇总,以最大程度地减少需要存储的原始数据量。汇总是一种汇总或预聚合的形式。在某些情况下,汇总数据可以大大减少需要存储的数据大小,从而可能使行数减少几个数量级。但是,减少存储量确实需要付出一定的代价:Netflix无法查询单个事件,而只能以预定义的查询粒度进行查询。对于Netflix的用例,Netflix选择了1分钟的查询粒度。

在提取期间,如果任何行具有相同的维度,并且它们的时间戳在同一分钟内(Netflix的查询粒度),则这些行将被汇总。这意味着通过将所有度量标准值加在一起并增加一个计数器来合并行,因此Netflix知道有多少事件促成了该行的值。这种汇总形式可以显着减少数据库中的行数,从而加快查询速度,因为这样Netflix就可以减少要操作和聚合的行。

一旦累积的行数达到某个阈值,或者该段已打开太长时间,则将这些行写入段文件中并卸载到深度存储中。然后,索引器通知协调器该段已准备好,以便协调器可以告诉一个或多个历史节点进行加载。一旦将该段成功加载到“历史”节点中,就可以从索引器中将其卸载,并且历史记录节点现在将为该数据提供任何查询。

数据处理

随着维数基数的增加,在同一分钟内发生相同事件的可能性降低。管理基数并因此进行汇总,是获得良好查询性能的强大杠杆。为了达到所需的摄取速率,Netflix运行了许多索引器实例。即使汇总在索引任务中合并了相同的行,在相同的索引任务实例中获取全部相同的行的机会也非常低。为了解决这个问题并实现最佳的汇总,Netflix计划在给定时间块的所有段都已移交给历史节点之后运行任务。此计划的压缩任务从深度存储中获取所有分段以进行时间块化,并执行映射/还原作业以重新创建分段并实现完美的汇总。然后,由“历史记录”节点加载并发布新的细分,以替换并取代原始的,较少汇总的细分。通过使用此额外的压缩任务,Netflix看到行数提高了2倍。知道何时收到给定时间块的所有事件并不是一件容易的事。可能有关于Kafka主题的迟到数据,或者索引器可能会花一些时间将这些片段移交给Historical Node。

查询方式

Druid支持两种查询语言:Druid SQL和本机查询。在后台,Druid SQL查询被转换为本地查询。本机查询作为JSON提交到REST端点,这是Netflix使用的主要机制。

对集群的大多数查询是由自定义内部工具(例如仪表板和警报系统)生成的。

为了加快采用Druid的查询速度并实现对现有工具的重用,Netflix添加了一个转换层,该层接受Atlas查询,将其重写为Druid查询,发布查询并将结果重新格式化为Atlas结果。这个抽象层使现有工具可以按原样使用,并且不会为用户访问Netflix的Druid数据存储中的数据创建任何额外的学习曲线。

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

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

Portworx Essential上手操作指南

Portworx阅读(932)评论(0)

Kubernetes架构对于初学者来说还是比较复杂,尤其是在Kubernetes上运行有状态应用,有时用户还并不需要企业级规模的功能。因此Portworx发布Portworx Essentials版本,它为小型生产环境提供了所有必要的Kubernetes存储功能,而且是永久免费的。
下面让我们看看对于有状态应用的必要功能有哪些,以及如何开始安装和使用。
关于Kubernetes运行有状态应用的必要原则有哪些?
如果在Kubernetes上运行有状态应用,比如MySQL, Postgres, Kafka, Cassandra, Gitlab, WordPress, Jenkins,为了保持数据,需要满足一些必要的原则,如CAP原则就建议(https://dzone.com/articles/understanding-the-cap-theorem):数据需要保持一致性、可用、且容许分区。为了满足这样的原则,就需要进行数据管理。
开始上手操作!

安装Portworx Essentials前需要准备的列表在这里:(https://docs.portworx.com/start-here-installation/),也包括下面的最低硬件配置,同时用户需要已经把Kubernetes安装好。
注意:Portworx Essentials不能被安装在air-gapped环境中。如果需要在air-gapped的环境中运行有状态应用,需要安装Portworx Enterprise。在一个包括至少3个Worker Node的集群上安装完成Kubernetes之后,就可以开始安装Portworx Essentials了。可以先打开PX-Central(https://central.portworx.com/),登录后点击“Install and Run”。

在Install and run窗体,点击右上角的“New Spec”

在这里,你需要选择需要安装的Portworx产品的版本,选择“Portworx Essentials,”点击“>Next.”。
接下来根据提示,填写Kubernetes环境的相关配置信息。
到最后一步,需要同意Portworx Essentials的授权协议。
点击“Agree”,然后可以保存Spec文件,以及可选的元数据标签。
你可以下载 Spec文件,或者copy kubectl apply命令,在已经配置过kubectl的Kubernetes集群里运行。
用kubectl配置完Portworx Essentials,你可以用下面的命令监控Portworx Pods。
$ kubectl get po -n kube-system -l name=portworx
所有的Pods都运行起来后,就可以正式使用Portworx Essentials了。如果需要更深入的了解功能,可以访问Portworx Essentials的文档(https://2.5.docs.portworx.com/concepts/portworx-essentials/),以及查阅用户授权协议(https://portworx.com/essentials-license-agreement/)。

如果遇到任何问题,Portworx提供在线支持,可以回答和解决问题,以及提供升级。关于问题解决也有相关文档可以参考。(https://2.5.docs.portworx.com/portworx-install-with-kubernetes/operate-and-maintain-on-kubernetes/troubleshooting/troubleshoot-and-get-support/)

Golang之go module开发系列二–使用伪版本和GoCenter

JFrogchina阅读(679)评论(0)

Go模块已经为Go开发带来了秩序,但也存在一些潜在的混乱。管理模块尤其是伪版本可能很困难,尤其是在要进行一些最新更改的情况下。

JFrog GoCenter是一个免费的版本话棋模块仓库,现在它包含了一些重要的更新,可以帮助你坚持这个最佳实践。首先让我们看看伪版本是如何工作的,以及您可以期望从这些更改中得到什么。我们还提供了一些指导,让您在升级到1.13或更高版本时保持Go的构建工作。

Go 的模块版本化

对Go模块进行版本化是一个关键特性,它为开发人员提供了一种方法来确保他们的应用程序使用他们想要的依赖项。在对模块进行版本控制时,应用程序可以指定依赖的模块版本,因为我们知道模块版本与其他组件运行时兼容问题。

Go模块版本是通过在底层源存储库中标记其修订来分配的。go命令使用标准形式vX.Y.Z的语义版本控制,以此来描述模块的版本。版本号根据API的变化而变化,如下图:

从这个标准格式中,可以比较模块版本,以确定哪个应该被认为是最当前的,哪个应该被认为是最不当前的。

使用Pseudo-Versions(伪版本)

版本化的Go模块是已经发布的,供一般使用的模块,应该是大多数开发人员的首选。但是,在某些情况下,您不能发布模块的最新版本。

例如,一个团队可能需要在开发期间共享一个临时版本。特别是当一个依赖的项目还没有发布版本时,所以它还没有被标记上版本。类似地,您可能需要针对尚未标记(打tag)的提交进行开发。

要使用未标记版本的模块作为依赖项,必须通过其伪版本标识符引用它。伪版本的格式如下:

伪版本有三种可接受的形式:

· Vx.0.0-yyyymmddhhmms-abcdefxyz,当在目标提交之前没有使用适当的主版本进行早期版本提交时

· vX.Y.Z-pre.0.yyyymmddhhmms -abcdefxyz。当目标提交之前的最新版本提交是vX.Y.Z-pre时,

· vX.Y.(Z + 1) 0.yyyymmddhhmms -abcdefxyz。当目标提交之前的最新版本提交是vX.Y.Z时,

作为一种最佳实践,伪版本字符串不应该是手工输入的。go命令将接受普通的提交散列并自动将其转换为伪版本。此方法有助于根据生成的时间戳比较修订。

例如,一个go get命令可能只使用模块查询的提交散列(githash):

同时,这里存在无法让go命令自动生成伪版本存在问题:

·伪版本参与最小版本选择。如果它的版本前缀不准确,那么伪版本的优先级可能比随后的版本更高,从而有效地将模块固定到提交

·伪版本中的提交日期提供了伪版本之间的总顺序,因此如果它被编辑,就会打乱顺序

尽管有这样的建议,但有时我们会手工修改的go模块中可能存在一个伪版本。在其他情况下,完整的伪版本字符串可能由第三方工具生成。

更严格的规则Go 1.13

GO的发行版1.12,Go对伪版本引用进行了修改。大多数涉及伪版本的操作都接受版本字符串和日期的任意组合,并且只要该修订存在,就会解析为基础修订(通常是Git提交散列,git hash)。

然而Go 1.13的发布带来了更严格的规则,以解决上面提到的问题。Go 1.13对“Go”命令接受的伪版本进行了限制,使一些以前接受但不规范的版本无效。

现在,go客户端将针对版本控制元数据对伪版本的不同元素执行一些验证:

· 版本前缀的格式必须为vX.0.0,或者从命名修订版本的祖先上的标签派生,或者从包含命名修订版本本身上的构建元数据的标签派生。

· 日期字符串必须与修订版的UTC时间戳匹配。

· 修订的简称必须使用与go命令生成的字符相同的字符数。(对于git使用的SHA-1散列,为12位数字的前缀。)

· 仅当对应的主要版本需要伪版本,并且仅当基础模块没有go.mod文件时,伪版本才包含“ +不兼容”( ‘+incompatible’)后缀

· 即使从代理解析了模块之后,go客户端也会尝试从校验和服务器获取校验和内容,该服务器(Go sumdb)将执行相同的伪版本验证规则,并拒绝提供校验和内容,防止代理进行伪装

1.13之前的Go版本不执行有关伪版本组件的这些规则。这意味着,即使用户不应该手动生成伪版本,也可以在多个伪版本中使用相同的提交哈希,而不会出现任何问题。

如何修复不正确的伪版本

为了迁移到1.13,开发人员必须纠正所有不符合上述要求的伪版本引用。否则go客户端会标记一个异常:

go get golang.org/x/sys@v0.0.0-20190726090000-fde4db37ae7a: invalid

pseudo-version: does not match version-control timestamp (2019-08-13T06:44:41Z)

幸运的是,通过创建伪版本引用的go.mod文件很容易做到这一点。

如果go.mod文件require指令的伪版本不正确,可以通过以下方法更正此错误:

1. 用提交哈希字符串替换完整的伪版本引用4

运行go mod tidy以使go客户端执行正确的替换。

[if !supportLists]2.      [endif]如果其中一个传递依赖项引用了无效的伪版本,则可以replace在go.mod文件中使用指令来强制更正:

GoCenter 如何应对上述变化

GoCenter的目标是与Go版本无关(即使在1.13之前,我们也支持所有Go模块版本)。JFrog的社区工程团队已经对GoCenter进行了重要的更新,以支持Go 1.13的所有版本,我们正在进行进一步的更新,以满足Go 1.14的要求。

GoCenter现在通过重定向到正确的伪版本来帮助您遵从伪版本验证。当请求模块下载错误的伪版本时,GoCenter将使用正确的版本修改.info中的元数据。

要使用GoCenter,请设置GOPROXY

针对Go 1.12

对于Go 1.12用户,GoCenter将更新Go。用正确的伪版本保存在其存储库中的go.mod文件。GoCenter仍将提供在此更改之前在GoCenter中处理的不正确的伪版本。

针对Go 1.13

Go 1.13用户将收到一条错误消息,指出正确的伪版本。

以便在go.mod文件中更新正确的伪版本,Go 1.13用户只需要改变Go get包含伪版本中的提交哈希(git hash)部分。

如果希望覆盖此行为并让GoCenter提供前面处理的错误伪版本,则可以设置GOSUMDB= off。

Go 1.14对于Go Module的变更

正如我们所注意到的,JFrog正在修改GoCenter以支持Go 1.14。以下是该版本中可能会影响模块操作的一些更改,您可能希望了解这些更改:

1. Go命令标志

· go get命令不再接受-mod标志

· 如果没有顶级供应商目录并且go.mod文件是只读的,则默认设置-mod = readonly

· 引入了-modfile = file新标记,该标记指示go命令读取/写入备用go.mod文件,还将使用备用go.sum文件。尽管仍必须存在名为go.mod的文件才能确定模块的根目录

2.go.mod文件更改

· 除非明确要求或已经要求,go get不会升级到+不兼容的主要版本

· go命令(go mod tidy除外)不会删除require指令,该指令指定主模块的其他依赖项已经隐含的间接依赖项的版本

· 设置-mod = readonly标志时,go命令不会因缺少go指令或任何错误而失败

3. 模块下载

· go命令现在在模块模式下支持Subversion存储库

· Go命令现在包括来自模块代理和其他HTTP服务器的纯文本错误消息的摘要。仅当错误消息是有效的UTF-8且由垄断图形字符和空格组成时,才会显示错误消息。

和GoCenter一起前进

随着Go模块获得更大的接受度,标准肯定会改变。您可以依靠JFrog GoCenter来跟上这些变化,并在需求发展时帮助您克服障碍。

如果你还没有探索GoCenter的免费Go模块库,我们邀请你去探索!它有一个丰富的UI,可以帮助您检查所有600,000多个Go模块的数据,可以帮助您获得对所使用的GoLang依赖项的强大支持。

学习更多技术知识可以关注我们的在线课堂

关注微信公众号:JFrog杰蛙DevOs, 获取课程通知

K8S数据保护工具比较

Portworx阅读(1174)评论(0)

K8S数据保护工具比较:Cohesity、 Kasten、 OpenEBS、 Portworx、 Rancher Longhorn、 和Velero
数据保护对于客户越来越重要。从概念上来说,数据保护包括备份、高可用性、应用连续性、和容灾恢复。所有的企业都需要实施,测试和运维自己的数据保护策略,来避免在发生问题时对商业产生不利影响。随着数据在用户体验和商业流程中的作用越来越重要,对关键数据突然不能访问的问题的容忍度越来越低。根据Uptime Institute的报告(https://uptimeinstitute.com/data-center-outages-are-common-costly-and-preventable)

数据无法访问问题中41%的情况导致的损失均超过了百万美元。企业对高可用性的基础架构的依赖性逐渐增强。

 

因此,一个有效的数据保护策略可以使宕机时间极少,即便发生意外宕机,应用和数据也都可以快速的恢复。同时数据保护策略还需要确保数据的隐私性和合规性(比如GDPR和CCPA),现在越来越多的用户数据转移到了线上隐私合规愈发重要。

 

虽然数据保护是一个硬性需求,很多客户仍然做的不够好。传统的数据保护方式在单独主机环境里很出色,但在分布式或跨数据中心环境里就能力不足了。而Kubernetes环境是典型的分布式环境。传统的业务连续性和容灾恢复(BCDR)方案,无法支持现今运行在Kubernetes上的关键商业应用所要求的RPO(Recovery Point Objective)和RTO(Recovery Time Objective)。

由于每个应用和每个客户环境都各不相同,因此数据保护方式也多种多样。当我们考虑数据保护解决方案的时候,一些重要的问题我们首先需要思考:

 

  • 我是不是只需要在一个单独的数据中心里保护我的数据?
  • 我是否需要保护数中心内和数据中心外的数据,需要建立一个混合的数据保护方案?
  • 是不是合规部门对一些备份和恢复数据的存储位置有要求?
  • 应用对RPO和RTO的要求低还是高?
  • 是否需要对Kubernetes集群里的每一个应用都采用同样水平的数据保护方式?
  • 我们准备对数据保护方案花多少钱,可否对不同的应用采用不同的数据保护方式,以降低成本?

还有一些问题取决于你的目标,比如:

  • 即使出现服务器宕机,或者磁盘宕机,也需要保证Kubernetes应用的高可用。
  • 备份数据和应用的配置,这样我们可以在另一个环境里恢复它们。
  • 一旦出现数据中心服务中断,应用可以即时在另一个环境重启且没有数据损失。

我们可以把数据保护场景分为:

  • 本地高可用
  • 备份和恢复
  • 容灾恢复

这三种场景是所有企业级数据保护的基础,也是评估一个Kubernetes数据保护解决方案能力的重要要素。不同解决方案的客户要求可能各有不同,客户需要根据自身的需求来评估这些要素。通常来说,只有静态数据备份不足以完成有效的数据保护,本地高可用通常是必须的基础性需求。

本地高可用、备份和恢复、容灾恢复是评估一个Kubernetes数据保护解决方案能力的重要要素。

对于Kubernetes,数据保护是一个较新的领域,市场有一些解决方案提供。本文我们要分析Kubernetes应用数据保护领域的一些主要供应商(https://www.computerweekly.com/feature/Spread-of-Kubernetes-spurs-backup-and-disaster-recovery-products)。我们在博文中讨论的解决方案主要是为了保护Kubernetes中正在运行的应用、和应用中的持久性数据,而不是备份Kubernetes的节点服务或者etcd存储,明确这些有助于我们更好的理解数据保护工具和Kubernetes的数据保护。

本地高可用性
本地高可用性指的是保护发生在某单个数据中心的错误,或者是某单个可用性区域内的云平台的错误。当应用正在运行时,如果基础架构、应用或者节点发生错误,都被认为是本地的错误。当我们用Kubernetes数据保护工具来构建本地高可用时,应用的复本可以在用户无感觉的情况下快速恢复,达到对用户的高可用。一个在本地节点错误情况下,宕机的例子:https://thenewstack.io/overcome-stuck-ebs-volumes-running-stateful-containers-aws/。本地高可用性是数据保护的基础。为达到本地高可用性,一般通过建立本地数据复制集的方式。如果本地高可用性是通过从外部其它位置的备份数据恢复的方式进行,那就应该被归类为是备份恢复方案,因为恢复时间会比本地高可用性的方案长很多。

备份和恢复
备份和恢复方案,指的是把Kubernetes上的整个应用,从本地Kubernetes集群上,备份到非本地的另一位置的对象存储里(非本地指位于其他区域的公有云、私有云、或者是本地部署环境)。备份解决方案也可以有多个备份位置。备份通常是为了防止系统错误,或者为了应用的合规和监管要求。而Kubernetes备份,需要符合Kubernetes环境特点。包括:

  • Kubernetes资源,比如Secrets、服务账户、CRDs等
  • 应用配置和数据

这些对象对Kubernetes来说都需要被备份。传统的备份方案一般不会考虑这些Kubernetes的对象,而是通常只把应用所依赖的VM、服务器、磁盘作为备份目标。一个Kubernetes备份解决方案,不仅能备份单个应用,而且可以备份多个应用或者整个Kubernetes命名空间,同时也能够支持传统备份方式的内容,比如调度、Jobs、 retention、加密和分层。

 

一个Kubernetes备份必须包括Kubernetes的资源比如Secrets、服务账户、CRDs、应用配置和数据。

容灾恢复
与备份类似,容灾恢复也必须要包括Kubernetes的一系列对象,应用配置和数据。并且需要创建主站点之外的容灾站点,这样资源和持久状态能够在主站点出问题时快速恢复到容灾站点。容灾恢复系统也可以处理不同保护层级的RPO和RTO,取决于成本和商业需要的综合考虑。 

例如,如果应用不能承担任何数据丢失,那就必须设定零RPO的目标。如果要求没那么高,也可以设定15分钟RPO的目标。再例如,一个应用的RTO要求<2分钟,而另一个应用可以允许1小时之内的宕机时间。

 

容灾恢复系统必须规划应用如何配置才能够在容灾节点上有效的启动运行。这需要处理应用的元数据,例如标签和复制集等,让它们能够自动启动起来。如果Kubernetes的API不能够被理解和启动,就会产生宕机事故或者数据损失。

Kubernetes数据保护解决方案的比较
我们已经理解了数据保护的多种类型,我们接下来比较一下市场上的解决方案:*比较基于各解决方案提供商的网站和文档。

 

快速索引

X   –  没有这项功能,或者宣称有功能但没有找到任何支持性信息

❍ – 宣称有这项功能,但是功能较为薄弱

◑  – 宣称有这项功能,但是功能不完整

✅ – 宣称有这项功能,并且从网站上的文档来看功能完整

Cohesity
Cohesity在网站上介绍,“Cohesity保护Kubernetes命名空间的数据和应用状态。Web-Scale平台备份命名空间包括运行状态,而不仅仅是数据。”Cohesity是数据保护和存储领域的一个主要服务商,它近期也通过备份命名空间的数据和应用,开始支持Kubernetes。但是Cohesity仅仅针对整个命名空间,而不能保护命名空间内的每个独立应用。保护单独应用是很有必要的,因为不是所有命名空间内的应用都需要同一水平的保护级别。因此Cohesity保护的颗粒度还不够。另外Cohesity目前还没有Kubernetes主存储,也还没有基于Kubernetes的容灾恢复方案。由于Cohesity对于备份VM的传统解决方案积累很久,现在进入到对Kubernetes的支持,也是一个很好的解决方案。
Kasten
Kasten在网站上介绍,“K10数据管理平台,为Kubernetes而建,为企业运营团队提供易用、可扩展、安全的备份恢复、容灾恢复、和集群间应用迁移能力”。Kasten使用自身构建的存储系统 -EBS/RBD,不支持应用自身所在集群里的复制,因此它无法支持本地高可用。基于云端的块存储来构建Kubernetes卷,经常会由于Stuck Volumes导致应用的宕机。由于没有数据路径的组件,Kasten无法达到数据完全无损的零RPO,备份只能是异步的,因此恢复后的数据与最新的数据会有一定的不同。有时候企业在容灾恢复上的要求不高,但很多企业仍然在容灾恢复上需要零RPO。
OpenEBS
OpenEBS这样描述:“我们是应用和本地、网络或云存储之间的抽象层,通过OpenEBS可以减少维护工作量,降低存储成本并且简化管理。”OpenEBS主要集中在本地高可用,也可以和Velero集成来达到OpenEBS 数据管理即服务(DMaaS)。DMaaS能够把Kubernetes有状态应用以及持久数据进行迁移。本地部署、云部署等任意方式都可以互相迁移。相对于Cohesity只备份整个命名空间而非每个独立的Kubernetes应用,OpenEBS只备份独立的应用。应用层级的备份的确更加灵活,但很多客户仍然需要命名空间层级的备份。另外OpenEBS只能用来备份包含持久存储卷的有状态应用,而不能备份或迁移Kubernetes对象和应用配置。OpenEBS备份是基于Velero进行的,而Velero也有自身的局限性 – 不能提供完整的容灾恢复功能,而OpenEBS自身也没有容灾恢复功能的补充,虽然OpenEBS也可以提供类似Kasten那样的异步备份的容灾,但问题也是无法达到数据完全无损的零RPO。
Portworx
Portworx是一个端到端的Kubernetes存储和数据管理方案。包括基于容器的CaaS,DBaaS,SaaS,备份恢复,以及容灾恢复。Portworx被市场研究机构GigaOm评为全球第一的Kubernetes存储平台。GigaOm评价Portworx的功能完美适应大型客户与服务提供商的需求。Portworx解决方案支持复杂的Kubernetes基础架构,无论是本地部署还是公有云/混合云部署。在Portworx的支持下,所有的Kubernetes应用都可以获得容器原生存储能力,以及本地高可用、容灾恢复、备份、安全管理、多云间迁移的能力等。Portworx提供一个数据层能够伸展在低延迟的网络上,从而达到零RPO容灾恢复,本地应用的备份和命名空间的备份。Portworx一开始就支持本地高可用,以及后来推出的PX-DR和PX-Backup能够提供更加多样的数据保护能力。
Rancher Longhorn
根据Rancher的描述,Longhorn是“轻量的,可靠的,和强大的。你可以使用简单的Kubectl命令,或者使用Helm来把Longhorn安装到Kubernetes集群上。一旦安装完成,Kubernetes集群就具备了持久存储卷的支持。”虽然比起其他开源解决方案,Longhorn的社区较小,但它近期被接受加入了CNCF。Longhorn有DR Volume的功能,可以被设定成源卷和目标卷,这样卷可以在一个新集群上基于最新的备份被激活。这个很类似Kasten的DR解决方案,是基于备份的,因此无法达到零RPO的能力。同样由于也不含应用元数据,因此也无法达到Kubernetes应用层级的恢复。
Velero
Velero描述自己的解决方案:“一个开源工具,可实现安全的备份恢复、容灾和恢复,以及迁移Kubernetes集群资源和持久卷。”Velero自身只能支持无状态应用资源。但是用户可以选择增加插件来达到持久卷声明快照备份。另一个选择是Restic,它通过文件/拷贝方式来实现。Velero自身并没有解决Kubernetes应用的数据问题。但如果结合插件或者Restic一起使用,可以提供备份和恢复,以及基于异步备份的容灾恢复能力 – 类似OpenEBS和Kasten。但是一样也无法提供零RPO的容灾恢复能力。结语

希望这篇文章能够帮助您更多的了解Kubernetes备份和数据保护解决方案,以及它们与传统的容灾恢复方案或者备份恢复方案有什么不同。各种解决方案在目前云原生架构下的构建方式都各有不同,因此这需要用户根据自身的应用的实际情况与需要,为应用选择不同层级的数据保护机制,从而选择有效的数据保护解决方案。

 

参考文档:

 

[1]https://www.cohesity.com/resource-assets/solution-brief/Data-Protection-for-Entire-Kubernetes-and-Container-Application-Stack-Solution-Brief.pdf

[2] www.kasten.io/product/

[3] https://openebs.io/

[4] https://help.mayadata.io/hc/en-us/articles/360033401591-DMaaS

[5] https://github.com/longhorn/longhorn

[6]https://velero.io/

Captial One如何实现Artifactory HA集群的自动化维护

JFrogchina阅读(450)评论(0)

 

一、背景

本文整理自Hank

Hudgins,Capital One高级工程师,在JFrog

2019用户大会上的讲演《Automated Artifactory HA Pipeline》。

Capital One是美国最大的数字化银行之一,其IT管理方法和应用技术也极为敏捷,全球拥有上万研发,具备非常丰富的 DevOps落地经验。在Capital One的DevOps体系当中,有很多类似于JFrog Aritfactory的HA(高可用)应用服务集群。众所周知,HA集群的运维,如升级、扩容、打补丁等工作,要想在保持用户服务不中断,服务水平不降级的前提下完成,尤其是在像Capital One这么大规模的DevOps系统当中,是十分困难、复杂,和高风险的。

Captital One使用的Artifactory为其DevOps体系中的制品及依赖管理提供了企业级解决方案,拥有工作(primary)和容灾(HR)两类HA集群。Hank所在的Artifactory维护团队,针对Artifactory HA集群维护的难点,通过建设和运行自动化的流水线,在不影响用户使用和服务水平的前提下,自动、高效、保质地完成了诸如版本升级、配置更新、补丁加载等工作,并且在检测到问题时,还能够实现自动化的回滚。在本次讲演中,Hank就介绍了这套自动化流水线的组成与特色。

二、自动化流水线概述

Capital One采用这套可靠的自动化流水线,在Artifactory

HA集群的维护工作中获得了良好的收益:

首先是通过自动化加速了维护进程,使得开发人员能够集中精力进行研发,而不需要考虑重复性的部署和测试任务;其次,流水线的可复用性也为维护工作提供了便捷的可扩展性,通过修改相关配置,流水线就能在新的环境中进行部署;最后,流水线还提供了可以快速检测缺陷,并实现无缝、高效回滚的部署过程。

该自动化流水线是按下述方式组成的:

首先是利用Jenkins驱动整个流水线,并集成GitHub进行触发:

· 每个Pull Request会触发小规模的测试以得到快速反馈。这些测试不是HA集群范围的,但可以得到快速验证

· 每个Merge会触发研发环境HA集群范围的部署,并进行相关测试;

· 标签(Tag)被用来标记代码更新的验证阶段和对应的环境。

其次,利用Terraform创建基础设施,实现了“类”蓝/绿的发布。

最后,利用Chef

cookbook实现针对各种应用服务的操作和配置更新。除了Artifactory,这些应用服务还包括了相关用于反向代理的Nginx、监控的Datadog,以及日志收集的Splunk。

三、自动化流水线组成

接下来,Hank逐一介绍了这套自动化流水线各个阶段的任务及实现方式。

首先是代码的静态分析,针对Pull Request和Merge运行。分析的目的是对代码结构进行快速验证和反馈,确保其符合业界标准。流水线集成了一系列的Linter来实现针对不同类型代码的静态分析。

接下来是安全测试,这在流水线当中体现了“左移”的原则,能够在真正部署之前尽早的检测和发现潜在的安全漏洞。目前的安全测试分两类,一类是静态安全测试,即通过分析代码结构来发现如SQL注入、Cross-site脚本等安全隐患;另一类是JFrog Xray提供的依赖测试,检测三方依赖包中是否包含已知安全漏洞,并推荐对应的修复版本。

下一步是单元/集成测试,用于验证代码的更新不会破坏预期的功能。这一步测试也可以应用于Artifactory的Custom user plugin的测试。流水线通过启动包含Artifactory的容器,安装并测试这些custom plugin,确保其正确工作,而不需要连接到真正的Artifactory HA集群。

在完成了上述初步的测试之后,自动化流水线进入发布过程。首先要把部署相关的文件暂存到可靠的位置,这样在集群自动缩放的过程中不会依赖到其他系统,也包括Artifactory自身。目前,部署的相关文件,包括二进制包和Chef cookbook,都从Artifactory下载并缓存到S3存储上。

自动化流水线的部署阶段实现了“类”蓝/绿的部署过程,能够保证新集群的部署不会影响到Artifactory的正常服务:

1. 把用户流量切换到容灾集群;

2. 缩容现有工作集群,仅保留几个节点(保持和容灾集群的数据同步),不包括primary节点(由于Artifactory HA集群实现了多活的架构,每个节点都是支持读/写的,所以缩容primary节点并不会影响正常服务)。

3. 基于同样的数据库和S3存储,部署新的工作集群,包括新的primary节点。

4.当新的工作集群通过测试后,再把用户流量切换回新的工作集群。

5. 之后再对容灾集群进行升级部署。

在上述部署过程中,两个Artifactory集群之间始终保持着数据同步,所以从用户的角度来看,部署是无缝切换的。

部署完成之后,要立即对集群中的各个应用服务进行检测。Jenkins通过SSH通道访问新的服务,并运行测试,确保Artifactory、Nginx等应用服务运行正常,相关配置文件的内容、位置、权限都部署正确,以及所有的网络端口都正常开通。如果检测失败,将会启动回滚过程。

接下来要运行系列的测试,确保Artifactory的各个repository都工作正常,包括能够正确拉取Docker镜像。同时,也要检测新的系统配置是否会影响制品依赖的解析,以及对不同虚拟repository的制品上传。

最后,还要进行性能测试,确保部署后集群性能没有下降。目前是利用Jmeter来模拟产品级流量,尽可能的匹配峰值流量时的API调用频率。常规15分钟的负载测试作为流水线的一部分,而可选的1小时负载测试,只有大的变更时才会执行。

性能测试的难点在于流量的建模,这是因为Artifactory的全语言特性带来的复杂性,支持多种数据包类型,及对接相应的包管理系统。通过分析Artifactory日志,获得了用于测试的API调用序列。

最后,是自动化流水线当中的回滚机制。目前实现了两种回滚:

· In-region回滚。当部署后的测试失败时,马上启动自动化回滚,删除新的集群,并恢复旧的集群。

· DR容错回滚。当工作集群升级成功后,或监测几天用户流量,没有问题的时候再更新容灾集群。如果在这几天中发现问题,就会启动容错回滚:先把用户流量切换到DR集群,然后把工作集群回滚到之前版本,数据库回滚到之前的快照,再通过Artifactory

Replication同步数据,最后再把流量切换回回滚后的工作集群。

数据库的回滚是个难题。在大版本的升级过程中,可能会有DB schema的变化,这时自动化的数据库回滚很难实现,目前暂时还是通过手工操作来完成。

四、总结

Capital

One通过自动化流水线实现Artifactory HA集群的维护工作,获得了很好的效果和收益,加速了发布过程,提供了良好的可复用性和扩展性,也能够启动有效的回滚机制。

通过自动化流水线的应用也可以看出,即使如Artifactory这样成熟的商业化产品,也需要对基础架构和配置进行全面的测试。

最后,自动化流水线本身也是需要持续的投资和提升的。

 

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

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