Alpine Linux

平台项目管理规范(Go语言版本) 1 编码规范 go版本 go1.13.4 开发环境 linux/mac/windows git版本 2.7.3+ 是否需要go fmt 需要 是否需要代码检查 需要 是否需要golint 需要 是否需要本地自测 需要 是否需要go mod tidy && go mod vendor 需要 平台目录结构: apis api接口文档(goSwagger) APP-META 前端页面入口 bin 项目编译生成的二进制文件存放目录 configs 平台支持的模板配置模板 contrib 平台申请资源模板文件 daemon 平台的核心代码实现 docs 相关操作文档 hack 编译使用到的脚本文件 pkg 平台使用的公共方法 vendor 平台依赖存放的位置 Dockerfile 平台项目的容器化文件 Makefile 平台的编译文件 go.mod 平台模板根 go.sum 平台依赖包 main.go 平台的主函数入口 main_test.go 平台的单元测试 1.1 引包规范 项目开发过程中需要符合社区开发的项目规范标准: import 系统包 换行 import 项目包 换行 import 第三方包 我们需要知道系统的建设，尤其云端Poc项目的开发实现需要完全符合社区的开发需求工作，在系统引包的流程中需要按照 系统包 项目包 第三方包进行导入

默认情况下，pod接受来自任何来源的流量。网络策略有助于指定一组Pod如何相互通信以及与其他网络端点通信。NetworkPolicy使用标签来选择Pod，并定义规则以指定允许对选定Pod进行哪些通信。一旦在特定Pod上应用了NetworkPolicy，该Pod将拒绝不允许NetworkPolicy的连接。未由任何NetworkPolicy选择的Pod将继续接受所有流量。 在本文中，我们将看到Ingress和Egress NetworkPolicy的用法，其中Ingress是到Pod的传入流量，而Egress是从Pod传出的流量。 前提条件：具有至少1个工作节点的Kubernetes集群 一、入口网络政策 创建一个带有标签“ app-destination-pod”和服务的hello-web pod，在该服务上我们将允许端口8080上的传入流量。 kubectl run hello-web --labels app=destination-pod --image=gcr.io/google-samples/hello-app:1.0 --port 8080 -- kubectl get pod | grep hello-web kubectl get service | grep hello-web 使用以下内容创建入口定义文件，该文件允许端口8080上与标签“ app =

1. 容器化 Docker 的横空出世，给了容器技术带来了质的飞跃，Docker 标准化了服务的基础设施，统一了应用的打包分发，部署以及操作系统相关类库等，解决了测试生产部署时环境差异的问题。对于运维来讲，由于镜像的不可变性，更容易进行服务部署和回滚操作。利用各种第三方容器管理平台，实现一键部署、动态伸缩等操作变的轻而易举。 2. 基础镜像选择 在操作系统的选择上，可选择传统的 CentOS 、 Ubuntu 或者更为轻量化的 Alpine 。比如 CentOS 或者 Ubuntu 的镜像都在 100MB 以上，压缩后也都有大几十 MB ，而轻量化的 Alpine 3.10 版本镜像大小约为 5.58MB ，而它压缩后更是仅有 2MB 大小左右。 Alpine 操作系统是一个面向安全的轻型 Linux 发行版。它不同于通常 Linux 发行版，Alpine 采用了 musl libc 和 busybox 以减小系统的体积和运行时资源消耗，但功能上比 busybox 又完善的多，因此得到开源社区越来越多的青睐。在保持瘦身的同时，Alpine 还提供了自己的包管理工具 apk 。 关于基础镜像的选择，一个是考虑镜像的大小，另一个是只提供最小的依赖包。关于第二点，不同的服务所需要的依赖包是不同的，这里不再展开讨论，如果仅从第一点考虑的话， Alpine 肯定是首选，镜像越小，远程推拉越快

平台项目管理规范(Go语言版本) 1 编码规范 go版本 go1.13.4 开发环境 linux/mac/windows git版本 2.7.3+ 是否需要go fmt 需要 是否需要代码检查 需要 是否需要golint 需要 是否需要本地自测 需要 是否需要go mod tidy && go mod vendor 需要 平台目录结构: apis api接口文档(goSwagger) APP-META 前端页面入口 bin 项目编译生成的二进制文件存放目录 configs 平台支持的模板配置模板 contrib 平台申请资源模板文件 daemon 平台的核心代码实现 docs 相关操作文档 hack 编译使用到的脚本文件 pkg 平台使用的公共方法 vendor 平台依赖存放的位置 Dockerfile 平台项目的容器化文件 Makefile 平台的编译文件 go.mod 平台模板根 go.sum 平台依赖包 main.go 平台的主函数入口 main_test.go 平台的单元测试 1.1 引包规范 项目开发过程中需要符合社区开发的项目规范标准: import 系统包 换行 import 项目包 换行 import 第三方包 我们需要知道系统的建设，尤其云端Poc项目的开发实现需要完全符合社区的开发需求工作，在系统引包的流程中需要按照 系统包 项目包 第三方包进行导入

前段时间做了个 node 全栈项目，服务端技术栈是 nginx + koa + postgresql 。其中在 centos 上搭建环境和部署都挺费周折，部署测试服务器，接着上线的时候又部署生产环境服务器。这中间就有很多既无聊又费精力，吃力不讨好的"体力活"。所以就开始思考怎么自动化这部分搭建部署的工作，也就引出了 Docker 。 什么是Docker Docker 是比虚拟机还要轻量级的虚拟化技术，它虚拟化的实体就叫做容器。容器本身就是一个隔离了作用域的 sandbox ，同时它只包含了基础库和本身承载的服务，非常精简。容器运行起来后就只是宿主机中的一个进程而已，占用的资源是非常小的，这就为操作系统上运行容器集群创造了条件，可操作性和灵活性极佳。 镜像和容器又是什么关系呢？可以把镜像看成是类（ class ），容器看成对象（ object ），容器是由镜像实例化产生出来的，当然一个镜像可以生成多个容器。 客户端Docker 如果不在服务器，我们在客户端要怎么使用 Docker 呢？在 Windows 和 OSX 上可以使用 Docker Desktop ，再加上 Kitematic ，这两个都是桌面管理工具，常规的操作方面非常便利。 Docker Desktop 和 Kitematic 只是可视化了部分操作，命令行还是必备的，因为很多操作也只能命令行才行。 Docker基本操作

前言：开发人员使用的镜像alpine缺少相关依赖包，在制作镜像的过程中，总结如下命令，以备后续使用 更换使用源 查看本地使用源 使用阿里源镜像 sed -i 's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g' /etc/apk/repositories 使用科大镜像 sed -i 's/dl-cdn.alpinelinux.org/mirrors.ustc.edu.cn/g' /etc/apk/repositories 更新索引 update：从远程镜像源中更新本地镜像源索引，update命令会从各个镜像源列表下载APKINDEX.tar.gz并存储到本地缓存，一般在/var/cache/apk/(Alpine在该目录下) 安装命令 安装软件包 apk add --no-cache tzdata busybox-extras fontconfig ttf-dejavu tzdata 安装指定版本软件包 apk add tzdata=2019a-r0 卸载命令 卸载并删除packages apk del tzdata busybox-extras fontconfig ttf-dejavu 升级 upgrade命令升级系统已安装的所以软件包，当然也可指定仅升级部分软件包（通过-u或--upgrade选择指定）。 apk update

file Docker Docker镜像的首行从FROM alpine之类的镜像开始，但是最初的基础镜像是如何创建的，本文使用一个busybox创建一个基础镜像，相信在此过程中会对docker一些相关的概念有进一步的理解。 什么是基础镜像（base image） 简单来说，基础镜像就是没有From或者FROM scratch开头的Dockerfile所构建出来的镜像。比如alpine，这个很小的linux镜像目前只有4M左右 Docker常用镜像选择 因为Docker镜像是基于基础镜像来构建的，因此选择的基础镜像越高级，我们要做的底层工作就越少。 比如，如果构建一个Java应用的镜像，选择一个openjdk的镜像作为基础镜像比选择一个alpine镜像作为基础镜像要简单地多。 Docker镜像官网 Docker镜像官网（Docker Hub）: https://hub.docker.com 阿里云容器Hub：https://dev.aliyun.com Google镜像（gcr.io）：https://console.cloud.google.com/gcr/images/google-containers/GLOBAL （主要为Kubernetes相关镜像） 操作系统基础镜像 比如你要从Linux操作系统基础镜像开始构建，可以参考下表来选择合适的基础镜像： 镜像名称 大小 使用场景

文章索引 Docker从入门到DevOps系列目录 Docker从入门到DevOps| 第一篇：DevOps工程的基石 —— Docker Docker从入门到DevOps| 第二篇：Docker常用命令 —— 镜像与容器操作 Docker从入门到DevOps| 第三篇：Docker镜像封装以及提交镜像至阿里云镜像库 Docker从入门到DevOps| 第四篇：用Docker部署一个基于SpringBoot + vue 前后端分离的应用 Docker从入门到DevOps| 第五篇：一键部署你的应用 —— docker-compose初体验 Docker从入门到DevOps| 第六篇：初探DevOps思想，DevOps利器walle介绍 Docker从入门到DevOps| 第七篇：Docker + walle + SpringBoot + Git实现项目的DevOps（一） Docker从入门到DevOps| 第八篇：Docker + walle + SpringBoot + Git实现项目的DevOps（二） Docker从入门到DevOps| 第九篇：Docker + walle + SpringBoot + Git实现项目的DevOps（三） Docker从入门到DevOps| 第十篇：初探Docker、Kubernetes与微服务思想 前言

我们在的项目组呢，有一项工作是，收邮件（很大程度上使用邮件是为了存个底），然后从我们的系统里边查一下相关信息，然后回复个邮件的工作。虽然工作量并不大，但是会把时间切的稀碎。为了拯救我的时间，所以做了一个邮件的值班机器人。让他来顶替我自动回复邮件，考虑到这个东西应该也有不少人会用得到，所以就把这个东西分享出来。先把效果分享出来。 服务器上就很简单，dutyrobot就是Golang编译之后的框架。lua文件夹中就是使用lua编写的业务逻辑。Data.json就是保存了一些相关的数据，防止重启之后，数据丢掉，比如说Cookie信息。 用最基础的alpine进行启动一下，并且将相关的文件夹映射到容器里边，然后在容器里边启动软件。这么做主要是为了让镜像能够拥有自己的环境变量。 然后业务逻辑里边定期，收邮件，然后判定业务逻辑，执行对应的lua脚本，然后回复邮件。 在顺手往我们的内部事务群里边推一条相关结果。 其实我本职是C#程序员来着，做这个东西，最先也是使用C#来实现的，不过C#跟Lua相性不好，我没有找到比较优雅的类库。要上Linux系统，用.net core + C 调用lua的方式虽然也尝试过，但是我本身对这件事情还是非常虚的。Python的各种包安装都给我搞蒙蔽了。所以最后就选用了Golang来写底层函数公布给Lua，然后让lua来写各种业务逻辑的方式来实现整个项目。框架部分嘛

我们在的项目组呢，有一项工作是，收邮件（很大程度上使用邮件是为了存个底），然后从我们的系统里边查一下相关信息，然后回复个邮件的工作。虽然工作量并不大，但是会把时间切的稀碎。为了拯救我的时间，所以做了一个邮件的值班机器人。让他来顶替我自动回复邮件，考虑到这个东西应该也有不少人会用得到，所以就把这个东西分享出来。先把效果分享出来。 服务器上就很简单，dutyrobot就是Golang编译之后的框架。lua文件夹中就是使用lua编写的业务逻辑。Data.json就是保存了一些相关的数据，防止重启之后，数据丢掉，比如说Cookie信息。 用最基础的alpine进行启动一下，并且将相关的文件夹映射到容器里边，然后在容器里边启动软件。这么做主要是为了让镜像能够拥有自己的环境变量。 然后业务逻辑里边定期，收邮件，然后判定业务逻辑，执行对应的lua脚本，然后回复邮件。 在顺手往我们的内部事务群里边推一条相关结果。 其实我本职是C#程序员来着，做这个东西，最先也是使用C#来实现的，不过C#跟Lua相性不好，我没有找到比较优雅的类库。要上Linux系统，用.net core + C 调用lua的方式虽然也尝试过，但是我本身对这件事情还是非常虚的。Python的各种包安装都给我搞蒙蔽了。所以最后就选用了Golang来写底层函数公布给Lua，然后让lua来写各种业务逻辑的方式来实现整个项目。框架部分嘛