K8S部署时镜像相关注意事项

最近部署K8S应用时发现一些小细节,记下来做个备注。

 

1.默认的部署只能pull到公库镜像,如果想要pull到私库镜像,需要进行额外配置,在spec节点下新增 以下内容:

imagePullSecrets:
– name: 私库字典Key

 

2.部署应用时,默认不会每次都拉最新镜像,所以需要在containers节点的resources节点下新增或修改一下内容:

imagePullPolicy: Always

代表每次部署都拉取最新镜像

K8S为某个命名空间添加私有仓库认证信息

我的K8S集群是分了命名空间的,所以教程上的普通方法不可用,因为默认的只给default空间添加了认证信息,所以当你在其他命名空间创建应用部署的时候,会提示pull error。

 

区别如下:

kubectl create secret docker-registry my-regsecret-name –docker-server=私有docker仓库域名 –docker-username=账号 –docker-password=密码 –docker-email=你的邮箱

上面的方式默认添加到default空间,下面方式添加到特定空间:

kubectl create secret docker-registry my-regsecret-name –namespace=命名空间  –docker-server=私有docker仓库域名 –docker-username=账号 –docker-password=密码 –docker-email=你的邮箱

记一次DataX导致的数据同步断头路(二)

经过几天的尝试,发现在DataX层面、数加层面是真的无法解决这个问题了,我调整了策略,计划使用MongoDB的自定义方法来实现,我在MongoDB中创建了一个名为“TS10”的方法,用于将”2018-06-06 18:00:00″这种字符串转为10位时间戳。

一切准备就绪,自定义方法也创建完成了,一切都很顺利。

当我想要实践的时候,突然发现阿里云的MongoDB团队出于安全考虑,全局禁用了db.eval()方法,这样一来,我的自定义方法无法运行,也就无法提供给DataX调用了。

再次断头。

记一次DataX导致的数据同步断头路(一)

最近因为业务需要,想要把Mongodb中的某些数据打入到阿里云的OpenSearch中进行检索,在同步的过程中遇到一些问题,导致暂时没能进行下去,这里做一次笔记。

images

可以看到的是,阿里云的DataX中,Mongodb Reader使用的是Mongo SDK(JAVA),所以不能像直连MongoDB数据库那样执行mongo shell,也就不支持JS语法,也就无法实现字符转10位时间戳的效果。

而又因为数加平台本身不提供底层的字符串转时间戳的能力,所以也不能在数加平台进行处理。

此处断头,暂时无法解决,如果后续解决了,再更新一下。

居然得了水痘,很逗!

可能是最近在高铁站被别人传染了,回来发了2天的烧,然后一个个出疹子。去医院看,不收治,只能去江宁的传染病医院看,折腾一上午,开了几盒药。

张老师说,人在艰难时,会出现心理倒退现象,所以可能会从心理层面反馈到生理层面,否则成人的免疫力很难得水痘的。说的也有点道理吧,哈哈。

过分在意主流意见的弊端

前段时间,《缝纫机乐队》和《羞羞的铁拳》同时上映,我先看的缝纫机,感觉很好,算得上用心。但是看完在淘票票里发现清一色的说垃圾,不如铁拳云云,当时觉得心情有点复杂,我如果先看到了评论,我还会去看嘛?我还会觉得好看吗?这是值得反思的,内心强大的人可以不被别人影响,但是你可以时时刻刻不被别人影响吗?很难。

如同我看完《妖猫传》,觉得是一部精品,陈凯歌这次的作品还算可以,演员偶有瑕疵,可以理解,整体的盛唐气息,贵妃气度,都表现的淋漓尽致。但是评论还是清一色的喷,但据说最近头条风气开始变了,觉得这片子分数能涨点。

所以,过分在意主流意见未必是好事,因为主流意见是可以被引导的。生活是如此,技术也是如此。

云效(原RDC)如何构建一个基于Maven的Java项目

最近在将公司的持续集成架构做一个系统的调整,调整过程中受到了RDC团队大量的帮助,所以利用国庆时间写了几篇RDC的分享,希望能让更多的人了解和用好RDC这个产品。

我会把我最近3个月的使用体会分成5个部分:使用RDC的动机、PHP项目集成、JS项目集成、JAVA项目集成、Docker类项目集成这5个分支来写

因为近期RDC的迭代比较频繁,所以我的分享会比较的浅,点到为止,仅供参考,目录:

1、RDC如何耦合进我们的业务

2、如何构建一个基于Composer的PHP项目

3、如何构建一个基于NodeJS的前后端项目

4、如何构建一个基于Maven的Java项目

5、RDC + 容器服务完成持续集成


一、RDC基础操作

在开始一切之前您需要熟悉RDC的一些基础操作,创建一个项目,然后在这个项目中创建一个应用,然后让这个应用关联某个代码分支。这样基础工作就完成了,我这里不再赘述了,因为比较简单,只需要注册个阿里云账号,然后去 rdc.aliyun.com 创建/加入个企业就行了。

本文所有的体验均基于【自由模式】的应用。

值得一提的是,应用代码源目前支持的是阿里云的代码仓库,基于gitlab,地址是 code.aliyun.com,从我2年的使用经验来看,还算好用,也不收费,较为靠谱。

在创建应用时,我们需要选择对应的配置

创建完应用后,进入【项目】–》【流水线】,找到刚才创建应用的【同名流水线】

点击流水线名称可以看到具体的流水线运行情况和对应节点

可以看到有4个面板:构建、日常、预发、正式。

分别对应的是:构建打包、发布到日常环境、发布到预发环境、发布到正式环境。

RDC在创建应用时自动的为你生成了一个标准模板流水线,但是我们一般用不着,所以需要对流水线进行修改,去除无用的节点,添加我们自己的配置。点击界面上的【编辑流水线】按钮就可以进入修改界面。

我们先从构建开始,所以先暂时删除日常、预发、正式这3个部署节点,仅保留构建这一个节点即可。下面的配置暂时不进行调整。删除完毕后保存流水线即可,效果如下:

至此我们已经完成了基础的准备工作,下一步就开始进行代码的构建工作了。

在开始下一步工作之前,请重新git pull一下您的代码到本地,会看到一个由RDC服务自动生成的配置文件:xxx.release 这个文件相当重要,请注意,下面将会说明如何通过此文件完成个性化构建。


二、基于Maven的Java项目构建

因为java类项目一般都通过maven来维护第三方库,并且一般会通过maven来进行构建,所以在RDC构建时需要完成依赖下载及编译的相关工作。

这里需要找到我们上一章节中提到的:xxx.release 文件,xxx代表你的应用名,所以我这里看到的文件名是:ms-autotags.release

这个文件的配置规范可以参考:https://help.aliyun.com/document_detail/59293.html

打开这个文件可以看到,已经有一些预先定义好的配置:

# 构建源码语言类型
code.language=scripts

# 应用部署脚本
deploy.appctl.path=deploy.sh

# Docker镜像构建之后push的仓库地址
docker.repo=registry.cn-hangzhou.aliyuncs.com/xxx/abced

上面的配置是不能用的,我们需要将其修改为如下内容:

# 语言类型,需要修改,否则无法调用对应的构建环境
code.language=java

# JDK版本
baseline.jdk=jdk-1.8

# 构建打包所用的maven版本
build.tools.maven=maven3.2.5

#产出物
build.output=target/ms-autotags-1.0-jar-with-dependencies.jar
# 应用部署脚本,先注释掉,暂时用不上
# deploy.appctl.path=deploy.sh

↓↓↓↓ 配置说明:

code.language=java

代表使用的是java作为代码语言类型。支持以下枚举(因为RDC经常更新,请以官方为准):

php5.6,php7.0,node6.x,node7.x,node8.x,oracle-jdk1.7,oracle-jdk1.8, oracle-jdk1.9,scripts

如果有使用过jenkins的同学,那么应该比较好理解,RDC的构建是通过Docker容器技术实现的,类似于配置好环境的jenkins构建机,RDC团队针对各种语言准备了不同的镜像作为构建宿主。


build.tools.maven=maven3.2.5

使用3.2.5版本的maven。


build.output=target/ms-autotags-1.0-jar-with-dependencies.jar

指明一个产出物,可以是目录也可以是具体的文件,比如jar包或者war包。如果执行完构建后此目录、文件不存在,则代表构建失败,无法进入工作流下一环。


简单maven项目不需要设置 build.command,除非你需要设置特别的maven打包参数或有多行打包命令。


我们已经完成了应用的创建+流水线的修改,那么我们运行一次构建试一下,只需要点击【运行流水线】按钮即可,运行后等几秒刷新一下页面,效果如下:

image

可以看到执行时间、版本号、日志、操作人等信息。

如果构建失败了,可以通过构建流程—-日志详情面板看到具体的错误原因,有日志排查起来不太难,但是RDC的构建还是偏向黑盒,所以尽量熟练或在本地先把相关命令跑通后再上传到xxx.release文件里去进行RDC构建。

可以看到初始的版本号是:v0.0.1-1,如果你的构建一直失败,版本号会变成v0.0.1-3、v0.0.1-8、v0.0.1-18、v0.0.1-N。

如果你的流水线全流程跑完了,则会自动叠加一个小版本号变为v0.0.2-1,所以这种构建方式清晰明了,还算好用。


三、如何输出为一个Docker镜像

我们已经完成了代码的打包编译工作,下一步我们需要把完整的代码封装成一个Docker镜像,我们需要对xxx.release文件做如下改动:

# 语言类型,需要修改,否则无法调用对应的构建环境
code.language=java

# JDK版本
baseline.jdk=jdk-1.8

# 构建打包所用的maven版本
build.tools.maven=maven3.2.5

#产出物
build.output=target/ms-autotags-1.0-jar-with-dependencies.jar

# Docker 构建配置
docker.file=Dockerfile

# Docker镜像构建之后push的仓库地址
docker.repo=registry.cn-hangzhou.aliyuncs.com/xxx/abced

docker.tag=ci-${PACKAGE_LABEL} 

# 应用部署脚本,先注释掉,暂时用不上
# deploy.appctl.path=deploy.sh

相对于单纯的构建,如果需要生成Docker镜像则需要补充几个配置项,拆解说明如下:

docker.file=Dockerfile

指明dockerfile文件的位置和文件名,默认就是根目录下的Dockerfile文件。


docker.repo=registry.cn-hangzhou.aliyuncs.com/xxx/abced

指定你的docker镜像仓库,建议使用阿里云提供的仓库,免费,速度快,可以加速docker hub的内容,无缝对接RDC服务,地址是 dev.aliyun.com ,此处的xxx对应的是你的名称空间,abced对应的是你的镜像名称。


docker.tag=ci-${PACKAGE_LABEL}-${TIMESTAMP}

这里指定你的docker镜像的tag名,使用了环境变量进行拼接。

${PACKAGE_LABEL}代表的是包名,这个参数在流水线配置里可以改,默认是default。

${TIMESTAMP}代表的是当前时间戳,格式是:20171008224350 这种样子。

有的项目一份代码可能产生多个docker镜像就需要通过这种方式来动态生成tag名,防止覆盖,也便于回滚。

关于构建传参,可以参考这个文章: https://help.aliyun.com/document_detail/59297.html

那么此处最终生成的tag名是这样的: ci-default-20171008224350

结合仓库名和镜像名,最终会生成镜像tag地址为:

registry.cn-hangzhou.aliyuncs.com/xxx/abced:ci-default-20171008224350


四、后记

NodeJS构建 + Docker构建就说到这里,因为主要是为了介绍RDC,所以Docker部分就挑重点讲了,如何编写Dockerfile文件请自行学习。

输出成Docker镜像后,如何使用RDC部署到容器相关问题我会单独开一个文章来分享。

阿里云VPC的使用体会分享(二)

本篇主要分享一些简单的基于VPC的产品架构搭建以及搭建过程中遇到的一些问题和踩过的坑。


在《阿里云VPC的使用体会分享(一)》中我曾经介绍了EIP和SLB两种方式让VPC-ECS具备公网或部分公网能力。


本文再深入一下,介绍如何结合EIP、SLB、VPC搭建产品架构。


分享下面一个场景,以及我己的解决之道:

有些公司因为历史原因网络架构会比较复杂,业务与业务之间在不同的地域(或机房,或服务商),业务与业务之间使用公网IP完成数据交互,只允许单点入、单点出,且业务与业务间的交互使用IP白名单进行控制,这种情况下,如何使用阿里云VPC来管理公司的云上ECS资产并与其它业务完成对接

 

首先提炼几个要素:


1.需要一个统一入口,且这个入口对安全性有较高的要求。


解决方案:使用公网SLB作为统一入口,这样的好处是公网IP不能直连具体的ECS,而是通过端口监听与转发完成数据交互,且通过SLB可以弹性增减后端ECS,提高流量的抗压能力和业务稳定性。




2.需要一个统一的出口。


解决方案:统一入口已经使用SLB完成了接入,但是SLB不具备公网出口能力,这一点我在第一篇文章中已经做了说明。那么依托SLB只能完成统一公网入口的搭建,公网出口有3种方式可以实现:


①为所有的后端ECS绑定一个EIP,这样就具备了公网出口能力。问题很明显,如果后端机器大于1台,则只能做到公网出口搭建,不满足出口IP固定的需求,且为VPC-ECS绑定EIP本身具有一定的风险性。


②在VPC环境中,挑一台机器绑定一个EIP,并搭建SNAT服务(或VPN服务,原理一致,后面就不重复了),然后将VPC网络的0.0.0.0下一跳设为此ECS,用于VPC内部的流量对外转发,自建SNAT有很多种方式,我这里就不一一赘述了。
优点:无论VPC有多少个ECS,都能统一的拥有公网出口能力,且公网出口唯一、一致。
缺点:SNAT服务器本身的稳定性和会影响到整个VPC内业务稳定性,单点风险很高。


③买买买,阿里云本身提供VPC内的SNAT服务,花钱就行了,本身也不需要搭建和维护SNAT服务器,省心省力。如果你的VPC网络里指定了0.0.0.0的下一跳,则无法购买,需要先删除。


以上我提供了3种解决办法,只有适合与不适合,小型业务适合方案①,中型适合②,大型和超大型的业务适合方案③。


使用方案②和方案③最终的效果是这样的:








其实这种方式来组建VPC业务群还可以应用到一些第三方服务的对接上,比如友盟的消息推送、阿里云的短信API等,这些都是需要通过白名单验证的,VPC的统一出口可以解决白名单维护难度。


上面的方案是VPC应用中纯云端的方案,也比较简单,适合简单的业务。VPC还可以对接线下的机房,构建自己的混合云等,后面再介绍。

阿里云VPC的使用体会分享(一)

使用阿里的VPC网络已经大约有3年时间了,抽时间把相关的东西做个笔记,也算是分享吧,这里的VPC指的是阿里云的VPC服务。


首先,VPC也是分地域的,而且一个地域可以存在多个VPC专有网络,有以下的特性:


1.VPC里的ECS服务器默认不会像经典网络的ECS一样分配公网IP,它需要通过其他方式完成公网接入。


2.要求有一定的组网能力,可以通过新增交换机来划分网络区域,对使用者而言有较高的要求,并且小型用户并不是必须使用这个产品。


3.最重要的一个能力,就是安全性,因为资源池与所有其他的阿里云客户形成了逻辑硬隔离,并且结合交换机、安全组可以完成更高的安全性调配方案。


针对VPC的模式,分享几个过程性方案:


【公网暴露方案】


因为VPC默认没有公网,所以不具备接入公网的能力,无论是接收还是发送,都无法办到。那么我们在使用过程中,有几种方式可以让VPC-ECS具备访问外网的能力。


1.为某个VPC-ECS绑定一个EIP弹性公网IP,收取IP租用费+流量费,绑定后此ECS将直接暴露在公网中,具备接收与外发两种能力,与经典网络的ECS毫无二致。需要警惕黑客通过绑定了EIP的机器做跳板打穿你整个VPC网络!


2.创建一个公网SLB负载均衡,收取实例租用费+流量费,把某个(些)ECS作为此SLB的后端机器。设置好相应的监听规则,可以完成请求转发TCP/UDP都行。但是值得注意的是,通过这种方式,只能让VPC-ECS具备公网接收能力,而不具备公网外发能力,具体例子:


SLB的公网IP为:8.8.8.8,指向了VPC-ECS01这个机器,配置了端口监听8080 to 8080,那么你使用浏览器访问8.8.8.8:8080可以直接访问到VPC-ECS01的8080端口,但是VPC-ECS01本身不能向外网发送任何数据,因为SLB的特性是单向的,只是请求转发,而不像EIP那样是一个双向通道。


值得一提的是,相较于EIP的方式,通过SLB的方式完成公网暴露可以提高安全性,降低内网被攻击的可能性。局限在于VPC-ECS依旧不具备公网外发能力。


我会再写一篇讲一下VPC下一些典型的应用构建架构和更高级的公网暴露方案。