已经忘记了很多事情
Ubuntu 和Debian以及CentOS这些内置源的NodeJS的版本和官方最新版差了个爷爷辈，所以需要安装新版的NodeJS要么去官方下包解压手动安装，要么找源进行安装。 本着方便的原则，当然是一键自动安装简单。因此发现了一个福利项目nodesource/distributions. 根据项目介绍.支持目前主流的Linux发行系统. 安装 RedHat系的系统包括 CentOS 和 Fedora，只需curl -sL https://rpm.nodesource.com/setup_8.x | bash -后再执行yum install -y nodejs即可. 以下是 Debian 系的安装. Node.js v8.x: # Using Ubuntu curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash – sudo apt-get … “Linux下根据订阅源安装最新NodeJS开发环境”
Read More
前些天撸了Kubernetes 1.6 和 1.7 两个版本, 发现官方对它最大的改进在于权限. 自版本 1.6 起,Kubernetes 默认由 RBAC 授权. 在kube-apiserver这个服务的配置项中,有一参数项为–authorization-mode,这便是设置授权的模式,值项有: AlwaysAllow 总是允许 AlwaysDeny 总是拒绝 ABAC 基于属性的权限验证 Webhook 基于网络事件的回调钩子 RBAC 基于角色的权限验证 Node 基于节点验证. Kubernetes 1.7 新增 其他的不是重点,这里只需要理解 RBAC 这个权限授权模式. 之前发布的 1.8 的 alpha2 … “理解 Kubernetes的RBAC”
Read More
Calico 网络的部署类似之前的 Flannel 网络,只需替换掉 Flannel,其他都无需修改便可生效. 准备环境 Master节点的配置建议 2U2G 起，Node 节点的配置建议 2U2G 起. 系统为 CentOS 7 ,需要配置各个节点的名称,IP,全部流程使用 root 权限,关闭 SELinux 与 Firewalld 服务. 节点名称和IP 三个Master节点,既为master也为node,一个纯Node节点. Node Name IP master1 192.168.85.141 master2 192.168.85.142 master3 192.168.85.143 将每个节点的Hostname改为对应的Node Name: … “创建基于Calico网络的Kubernetes 1.7.6”
Read More
准备环境 Master节点的配置建议 2U2G 起，Node 节点的配置建议 2U2G 起. 系统为 CentOS 7 ,需要配置各个节点的名称,IP,全部流程使用 root 权限,关闭 SELinux 与 Firewalld 服务. 节点名称和IP 三个Master节点,既为master也为node,一个纯Node节点. Node Name IP master1 192.168.85.141 master2 192.168.85.142 master3 192.168.85.143 将每个节点的Hostname改为对应的Node Name: # master1 hostnamectl –static set-hostname … “创建基于Fannel网络的Kubernetes 1.7.6”
Read More
微服务架构 在容器技术大火的当下,将后台的应用微服务化,无疑是最优的选择,但微服务化并不是简简单单就能实现的. 微服务的概念是通过对应用功能的解耦.在明确各自的作用,将其分散到各自独立的运行环境中. 早期服务程序大都是单体的,它会囊括多种功能,这在编写代码,调试程序时都是比较耗时耗力的,并且一个功能庞大的单体服务程序,只要某个环节出现了问题,则会较大概率的导致整体的崩溃. 而当将这些功能打散后,规模和体积将会变得更加轻量化,代码编写只需完成其单一场景的作用,调试必将将会变得简单,而在编译/打包/部署等环节都会节约不少时间,这将大大的提高开发的效率. 从当下主流的微服务架构来说,首先会依据功能划分出Service Gateway,来自用户的 Request 到达后,这些网关负责鉴权与路由.通过验证的请求,会被该网关转发到内部的实际的某个微服务中去,而后此微服务完成功能后应答网关,网关再回应用户.这整个流程应该是异步的,尽量避免因某个环节导致整体的阻塞. 服务间调用 在将服务拆分后,会导致一个问题,那就是服务间复杂的依赖关系.比如现在最火的 SOA 型的微服务架构也是如此. 当将一个单体应用拆分开后,不可避免的需要于服务间进行一些数据共享,而共享方式则就是服务间调用. 基于此,微服务之间也必须要有明确的划分界限:哪下服务应该是对外的,哪些微服务又该是对内的? 比如在线好友的查询服务网关中,对外的服务很好确认,而对内的微服务相对较难界定.可以将专门查询好友数据的功能单一实现,通过统一的API,去查询好友数量,好友资料,好友在线状态等. 而有些时候,微服务间可能会出现数据互相依赖的现象,即服务A调用服务B去完成某项功能时,服务B在运行中又可能需要调用A的接口获取数据,这将会导致微服务间层级错落的现象,此时应该尽量将相互依赖的功能划分独立出来,否则在后来可能越来越背离微服务的架构旨意.
Read More
进行手动部署k8s的时候需要十分仔细和耐心,不然一步错那么将会是步步错. 使用命令kubectl get cs和kubectl gt csr返回正常,而到了kubectl get nodes的时候,返回No resources found. 则需要检查在部署kubelet是否配置正确且正常运行,检查kubelet.config配置文件是否生成.若是不存在配置文件,则需要检查kubelet运行状态\输出日志\启动配置,比如kubelet服务配置文件名就是kubelet.service,则可以使用命令systemctl status -l kubelet,journalctl -u kubelet 查看相关输出日志;以及可以查看iptables的规则是否正常.
Read More
提交流程图时,出现了如下奇怪错误: $ git push origin Counting objects: 4, done. Delta compression using up to 24 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 5.59 MiB | 16.73 MiB/s, done. Total 4 (delta 1), … “GitLab 使用git push 出现RPC failed; HTTP 500 curl 22 The requested URL returned error: 500”
Read More
之前在去年安装node.js时，yum install直接就搞定。这次虚拟机太久未登陆，于是登陆’yum update’遇到了如下错误: Error: Package: 1:nodejs-6.11.1-1.el7.x86_64 (epel) Requires: libhttp_parser.so.2()(64bit) Error: Package: 1:nodejs-6.11.1-1.el7.x86_64 (epel) Requires: http-parser >= 2.7.0 查了下,是因为CentOS 的EPEL里已经移除了Node.js而放在了REHL中。 因此需要去下载http-parser安装即可. rpm -ivh https://kojipkgs.fedoraproject.org/packages/http-parser/2.7.1/3.el7/x86_64/http-parser-2.7.1-3.el7.x86_64.rpm
Read More
群晖没 root 权限很不爽,网上搜了下还真找到了. 首先 Web 上登录后打开 Control Panel 切换到 Advance Mode,打开 Terminal & SNMP ,勾选 Enable SSH Service, Port使用默认的 22 号端口即可. 然后使用自己的账号 SSH 登录群晖后(必须要有管理员权限),sudo -i切换到 root 账户.打开 SSH 的配置文件/etc/ssh/sshd_config,添加PermitRootLogin yes到其中后,使用命令synouser –setpw username newpasswd修改root的密码. 最后一步就是重启 SSH … “Synology DSM 6使用root进行SSH登录”
Read More