Docker swarm 为 service 设置固定IP(失败,只能采取docker-compose的方式)

大数据评论10

原因

由于c平台项目特殊性,编译的时候需要确定各个节点的IP。因此需要将service的ip固定

尝试

在docker-compose.yml中加了如下配置

weblogic:
    image: weblogic:1.1
    #container_name: weblogic_1
    command: ['ping', '127.0.0.1']
    #restart: always
    networks:
      exnetwork:
        ipv4_address: 172.19.0.21

使用 doekcer stack deploy 启动后,发现IP并不是 172.19.0.21 ,而是随机的。

重启了几次,发现依然是这样

原因

查了下资料,发现本身就不支持...最详细的是这个页面

https://github.com/moby/moby/issues/24170

很多人有这个需求,但一直到现在也不支持...

类似的issue还有

https://github.com/moby/moby/issues/31860

https://github.com/moby/moby/pull/32981

解决办法

使用docker-compose

如果不是必须要用swarm集群,可以使用docker-compose来启动,只不过只支持单机了

使用over-node

项目URL

https://overnode.org/docs/custom-networking/

也是在github的issue看到了这个人的宣传,号称支持service固定IP,可以理解成多个节点的docker-compose。

但不太敢用,怕踩坑

docker 使用 macvlan 网络模式

macvlan是Linux本身的一种特性,参考这篇文章

https://mp.weixin.qq.com/s?__biz=MzI1OTY2MzMxOQ==&mid=2247485246&idx=1&sn=c42a3618c357ebf5f6b7b7ce78ae568f&chksm=ea743386dd03ba90ad65940321385f68f9315fec16d82a08efa12c18501d8cadf95cf9e614a2&scene=21#wechat_redirect

docker本身现在也支持这种网络模式,

使用macvlan可以是多个主机的container进行通信,但存在一个问题: host无法直接访问container,反之container也无法直接访问host.

原因是出于 安全考虑(不过如果host本身有2块网卡,似乎可以解决这个问题)......

Docker swarm 为 service 设置固定IP(失败,只能采取docker-compose的方式)

参考自 https://forums.docker.com/t/macvlan-networks-unable-to-connect-to-host-from-container/51435/4

macvlan体验

参考

https://www.cnblogs.com/bakari/p/10893589.html

https://docs.docker.com/network/macvlan/

环境说明:

Host1  192.168.137.2  ens0
Host2  192.168.137.3  ens0

Container1  192.168.0.2  dockervlan  (Host1)
Container2  192.168.0.3  dockervlan  (Host2)

创建过程比较简单,参考下面这个docker-compose.yml

version: '3.7'

services:
  tuxedo:
    image: tuxedo:1.1
    hostname: 'test'
    #container_name: tuxedo_1
    #restart: always
    command: ['ping', '127.0.0.1']
    environment:
      TUXCONFIG: '/home/wang/OraHome_1/tuxedo12.2.2.0.0/samples/atmi/simpapp_bak/tux.config'
    networks:
      dockervlan:
        ipv4_address: 192.168.0.2  # 另外一个Host上的docker-compose此处改为192.168.0.3
networks:
  dockervlan:
    #This interface should be defined as using null driver. Do not remove it.

    driver: null
    driver_opts:
      parent: eno1
    ipam:
      config:
        - subnet: "192.168.0.0/24"
          ip_range: "192.168.0.64/26"
          gateway: "192.168.0.1"
  dockervlan:
    #This is the interface which is used for containers networking
    driver: macvlan
    driver_opts:
      parent: eno1
    ipam:
      config:
        - subnet: "192.168.0.0/24"
          ip_range: "192.168.0.64/26"
          gateway: "192.168.0.1"

参考

https://github.com/sarunas-zilinskas/docker-compose-macvlan/blob/master/docker-compose.yml

两台服务器上安装好docker-compose,使用下列命令启动即可

 docker-compose up -d

可以在两个container上ping另外一个,可以发现是互通的。

但ping Host则失败,Host ping container也不行

使Host可以ping container

参考这里

https://rehtt.com/index.php/archives/236/

https://stackoverflow.com/questions/44048915/unable-to-access-docker-containers-from-host-over-macvlan-network

实际操作

ip link add macvlan2 link eno1 type macvlan mode bridge
ip addr add 192.168.0.5 dev macvlan2
ip link set macvlan2 up
ip route add 192.168.0.2 dev macvlan2

随后在Host1上ping 192.168.0.2发现已经可以返回结果了

原理:

相当于建立了两个macvlan网络,然后修改路由,把数据经过新建的macvlan去访问container

注意:

重启后会失效,可以设置开机启动。

不过由于这种方式不满足我的需求,因此测试后依然放弃

其他思路

有人使用 pipework 这个第三方软件,但没测试

pipework是一个400多行的shell程序,封装Linux上的ip、brctl等命令, 简化了在复杂场景下对容器连接的操作命令,为我们配置复杂的网络拓扑提供了一个强有力的工具.

参考

http://www.louisvv.com/archives/695.html

https://juejin.cn/post/6844903685248679950

Original: https://www.cnblogs.com/wswang/p/16133733.html
Author: wswang
Title: Docker swarm 为 service 设置固定IP(失败,只能采取docker-compose的方式)



相关阅读

Title: 云效研发效能度量体系,如何展示和解读交付效能数据

云效研发效能度量体系,如何展示和解读交付研发效能数据,一个迭代或者一个周期结束后,团队需要回顾复盘驱动研发效能改进,在回顾复盘前需要展示团队当前的研发效能数据。通过研发效能度量来度量团队是否具备了交付价值的能力。

作者:舍卫|阿里巴巴集团技术专家

阿里巴巴研发效能度量体系(如下图),通过五个维度来度量团队是否具备了「顺畅、高质量交付价值的能力」,包括需求响应周期、持续发布能力、交付吞吐率、交付过程质量和交付质量,期待能又快又多又好地交付需求。

1. 需求响应周期

具体包含两个细分的指标,分别是:

•交付周期:指的是从确认用户提出的需求开始,到需求上线所经历的平均时长。它反映团队(包含业务、开发、运营等职能)对客户问题或业务机会的响应速度;

•开发周期:指的是从开发团队理解需求开始,到需求可以上线所经历的平均时长。它反映技术团队的响应能力。

区分交付周期和开发周期,是为了解耦并明确问题,以做出针对性的改进。其中,交付周期是最终的目标和检验标准。

需求累计流图

云效有丰富的报表统计功能,接下来,我将带领大家一起来学习如何在云效上配置上面的报表。

如下图所示,从「统计」进入,点击「新建报表」,可以看到云效的新建报表列表。
说明立即体验:云效项目管理;

选择「效能分析」,然后点击「需求累计流图」出现如下图所示的报表:

每一个蓝色的点代表一个已经发布的需求,横轴是日期,纵轴是天数。这些蓝色的点越朝下越好,代表需求的交付时间越短,响应力也越好;散点的密度越高代表交付频率越高,散点横向上更均匀分布代表持续交付的稳定性越好。

交付周期趋势图

选择「效能分析」,然后点击「交付周期报表」

如下图,选择按月统计,任务选择「需求」,开始状态选「已选择」,结束状态选「已发布」,更新左上角的图表名称为「交付周期趋势图」后保存,即可展现。

开发周期趋势图

选择「效能分析」,然后点击「交付周期报表」

如下图,选择按周统计,任务选择「需求」,开始状态选「就绪(待开发)」,结束状态选「待发布」,更新左上角的图表名称为「开发周期趋势图」后保存,即可展现。

下图是开发周期趋势图示例,横轴是时间,按照自然周排列,纵轴是需求个数。每个柱子代表的是当周已到待发布状态需求的数量,各柱子由不同的颜色堆积而成,蓝色代表需求的开发周期时长小于1周,绿色代表需求的开发周期时长在1-2周之间,橙色代表需求的开发周期时长在2-4周之间,红色代表需求的开发周期时长大于4周。

从上图可以看出,需求开发周期在1周内的需求数量在持续增长,同时一周内的占比也在逐步提升,由于该数据是在8月15日取的,所以最后一周的数据还不全。

2. 持续发布能力

具体包含两个细分指标,分别是:

•发布频率:团队对外响应的速度不会大于其交付频率,发布频率约束团队对外响应和价值的流动速度。它的衡量标准是单位时间内的有效发布次数。

•发布前置时间(也被称为变更前置时间):也就是从代码提交到功能上线花费的时间,它体现了团队发布的基本能力。如果时间开销很大,就不合适加大发版频率

发布频率

从需求控制图上可以看出持续发布能力的变化,如果需求散点的密度越高,则交付频率越高,反之则越低。

发布前置时间

发布前置时间,与团队的工程能力有很大的关系,这和云效新品代码平台和流水线强相关,这里暂不做讲解。

3. 交付吞吐率

指的是单位时间内交付需求的数量。关于这一点,常见的问题是,个数能准确反映交付效率吗?这是个问题。所以,我们更多强调单个团队的需求吞吐率的前后对比,统计意义上它足以反映趋势和问题。

需求吞吐率趋势图(按周)

在需求响应周期的图表中,需求吞吐率的趋势也已呈现,下图中纵轴代表这一周发布需求的数量,所以柱子越高代表这一周交付的需求越多。

这里吞吐率的计算是按照需求的数量来统计的,在需求颗粒度大小差别很大的时候,吞吐率数据会出现偏差,所以在统计这个之前,期待团队能对需求进行拆分,拆分到工作量在2周之内。

需求吞吐率趋势图(按迭代)

在自定义图表中选择按迭代和任务状态,然后添加两个筛选条件:迭代和状态。迭代选择需要比较的几个迭代,状态只选已发布的需求。出现如下按照迭代进行比较的吞吐率趋势图。

4. 交付过程质量

它包含两个细分的指标,分别是:

•开发过程中缺陷的创建和修复时间分布:我们希望缺陷能够持续和及时地被发现,并且在发现后尽快修复;

•缺陷库存:我们希望在整个开发过程中控制缺陷库存量,让产品始终处于接近可发布状态,奠定持续交付的基础。

交付过程质量的核心是内建质量,也就是全过程和全时段的质量。而非依赖特定的阶段,如测试阶段;或特定的时段,如项目后期。内建质量是持续交付的基础,关于其具体度量方法,下文会给出详细实例。

缺陷趋势图

如上图所示,图中的横坐标是日期,横坐标上方红色竖条代表这一天发现缺陷数量;横坐标下方绿色竖条代表当天解决的缺陷数量;橙色曲线代表缺陷存量。图中左右两个部分比较了两种交付模式。

左半部分,团队属于小瀑布的开发模式。"迭代"前期,团队集中设计、编码,引入缺陷,但并未即时地集成和验证。缺陷一直掩藏在系统中,直到项目后期,团队才开始集成和测试,缺陷集中爆发。

小瀑布模式下,过程质量差,带来大量的返工、延期和交付质量问题。该模式下,产品的交付时间依赖于何时缺陷能被充分移除,当然不能做到持续交付,也无法快速响应外部的需求和变化。并且,这一模式通常都导致后期的赶工,埋下交付质量隐患。

右半部分,团队开始向持续交付模式演进。在整个迭代过程中,团队以小粒度的需求为单位开发,持续地集成和测试它们,即时发现和解决问题。缺陷库存得到控制,系统始终处于接近可发布状态。这一模式更接近持续发布状态,团队对外的响应能力随之增强。

缺陷趋势图从一个侧面反映了团队的开发和交付模式。它引导团队持续且尽早发现缺陷并及时移除它们。控制缺陷库存,让系统始终处于接近可发布状态,保障了持续交付能力和对外响应能力。

在项目「统计」中,选择「缺陷分析」,然后点击「缺陷变化趋势」出现如下图所示。

5. 对外交付质量

它包含两个细分的指标,分别是:

  • 单位时间的故障(线上问题)数;
  • 故障平均解决时长

这两者共同决定了系统的可用性。
加餐:了解研发效能度量详情,欢迎学习阿里巴巴研发效能提升36计第4课-设置北极星指标,数据驱动效能改进

小结

阿里巴巴研发效能度量体系,通过五个维度来度量团队是否具备了「顺畅、高质量交付价值的能力」,通过以上五组指标,从流动效率、资源效率和质量三个方面讲述了一个完整的故事,回答了目前组织持续交付价值的能力如何这个核心问题。其中,持续发布能力和需求响应周期这两组指标反映价值的流动效率;吞吐率反映资源效率;交付过程质量和对外交付质量这两组指标共同反映质量水平。

关于我们

更多关于云效DevOps的干货及云效动态,可微信搜索关注【云效】公众号~

彩蛋:公众号后台回复【指南】,可获得《阿里巴巴DevOps实践指南》&《10倍研发效能提升案例集》~

看完觉得对您有所帮助别忘记点赞、收藏和关注呦

Original: https://www.cnblogs.com/yyds114/p/15309386.html
Author: 云效DevOps平台
Title: 云效研发效能度量体系,如何展示和解读交付效能数据

相关文章
基于Docker搭建Nginx图片服务器 大数据

基于Docker搭建Nginx图片服务器

前言 一般来说,在开发中,图片会被上传到一个目录中,然后将目录和文件名拼接并存储在数据库中,但这种方法如果做得不好可能会有一些缺陷。[En]In general, in development, th...
GAIA-IR: GraphScope 上的并行化图查询引擎 大数据

GAIA-IR: GraphScope 上的并行化图查询引擎

导读: 验证码作为网络安全的第一道屏障,其重要程度不言而喻。当前,卷积神经网络的高速发展使得许多验证码的安全性大大降低,一些新型验证码甚至选择牺牲可用性从而保证安全性。针对对抗样本技术的研究,给验证码...
JVM GC算法 CMS 详解(转) 大数据

JVM GC算法 CMS 详解(转)

CMS,全称Concurrent Low Pause Collector,是jdk1.4后期版本开始引入的新gc算法,在jdk5和jdk6中得到了进一步改进,它的主要适合场景是对响应时间的重要性需求 ...
go kafka group 大数据

go kafka group

在以前的文章kafka初探go和C#的实现里面我们用了sarama来消费kafka的消息,但是很遗憾它没有group的概念。没办法 我们只能用sarama-cluster来实现, 注意sarama版本...
IO复用三种方式 大数据

IO复用三种方式

IO复用技术,简单来说就是同时监听多个描述符。在没有用到IO复用以前,只能是一个线程或一个 线程监听,当服务器同时有多个连接时,需要创建多个线程或进程。此外,并不是所有的公司[En]Threads l...
匿名

发表评论

匿名网友