Alpine Linux

1. java镜像 使用Java镜像的最直接方法是把它作为基础镜像或运行时环境。 1.1 镜像tag java:<version> 如果你不确定你需要什么，那么请用这个tag。它可以作为一个运行时环境，装载你的源代码，并启动你的应用程序容器；也可以作为基础镜像，用于构建应用镜像。 常用tag有： 6b38-jdk, 6b38, 6-jdk, 6, openjdk-6b38-jdk, openjdk-6b38, openjdk-6-jdk, openjdk-6 6b38-jre, 6-jre, openjdk-6b38-jre, openjdk-6-jre 7u111-jdk, 7u111, 7-jdk, 7, openjdk-7u111-jdk, openjdk-7u111, openjdk-7-jdk, openjdk-7 7u121-jdk-alpine, 7u121-alpine, 7-jdk-alpine, 7-alpine, openjdk-7u121-jdk-alpine, openjdk-7u121-alpine, openjdk-7-jdk-alpine, openjdk-7-alpine 7u111-jre, 7-jre, openjdk-7u111-jre, openjdk-7-jre 7u121-jre-alpine, 7-jre-alpine,

背景 随着容器技术的普及，越来越多的应用被容器化。人们使用容器的频率越来越高，但常常忽略一个基本但又非常重要的问题 - 容器镜像的体积。本文将介绍精简容器镜像的必要性并以基于 spring boot 的 java 应用为例描述最小化容器镜像的常用技巧。 精简容器镜像的必要性 精简容器镜像是非常必要的，下面分别从安全性和敏捷性两个角度进行阐释。 安全性 基于安全方面的考虑，将不必要的组件从镜像中移除可以减少攻击面、降低安全风险。虽然 docker 支持用户通过 Seccomp 限制容器内可以执行操作或者使用 AppArmor 为容器配置安全策略，但它们的使用门槛较高，要求用户具备安全领域的专业素养。 敏捷性 精简的容器镜像能提高容器的部署速度。假设某一时刻访问流量激增，您需要通过增加容器副本数以应对突发压力。如果某些宿主机不包含目标镜像，需要先拉取镜像，然后启动容器，这时使用体积较小的镜像能加速这一过程、缩短扩容时间。另外，镜像体积越小，其构建速度也越快，同时还能减少存储和传输的成本。 常用技巧 将一个 java 应用容器化所需的步骤可归纳如下： 编译 java 源码并生成 jar 包。 将应用 jar 包和依赖的第三方 jar 包移动到合适的位置。 本章所用的样例是一个基于 spring boot 的 java 应用 spring-boot-docker，所用的未经优化的

pod是kubernetes的最小单元，自主式创建的pod删除就没有了，但是通过资源控制器创建的pod如果删除还会重建。pod控制器就是用于实现代替我们去管理pod的中间层，并帮我们确保每一个pod资源处于我们所定义或者所期望的目标状态，pod资源出现故障首先要重启容器，如果一直重启有问题的话会基于某种策略重新编排。自动适应期望pod数量 pod控制器类型简介： 　　1.ReplicaSet: 　　　　代用户创建指定数量的pod副本数量，确保pod副本数量符合用户期望的数量状态，如果少了多退少补，并且支持滚动式自动扩容和缩容机制。 　　　　ReplicaSet主要三个组件组成：　　 　　　　　　（1）用户期望的pod副本数量 　　 　　　　　　（2）标签选择器，判断哪个pod归自己管理 　　 　　　　　　（3）pod资源模板（当现存的pod数量不足，会根据pod资源模板进行新建帮助用户管理无状态的pod资源，精确反应用户定义的目标数量。不直接使用） 　　Deployment： （无状态，守护进程类，只关注群体不关注个体） 　　　　工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。（pod数量和node没有精确的配比，没有一对一的关系） 　　DaemonSet：（无状态，守护进程类，只关注群体不关注个体） 　　　

转载于网络 pod是kubernetes的最小单元，自主式创建的pod删除就没有了，但是通过资源控制器创建的pod如果删除还会重建。pod控制器就是用于实现代替我们去管理pod的中间层，并帮我们确保每一个pod资源处于我们所定义或者所期望的目标状态，pod资源出现故障首先要重启容器，如果一直重启有问题的话会基于某种策略重新编排。自动适应期望pod数量 pod控制器类型简介： 　　1.ReplicaSet: 　　　　代用户创建指定数量的pod副本数量，确保pod副本数量符合用户期望的数量状态，如果少了多退少补，并且支持滚动式自动扩容和缩容机制。 　　　　ReplicaSet主要三个组件组成：　　 　　　　　　（1）用户期望的pod副本数量 　　 　　　　　　（2）标签选择器，判断哪个pod归自己管理 　　 　　　　　　（3）pod资源模板（当现存的pod数量不足，会根据pod资源模板进行新建帮助用户管理无状态的pod资源，精确反应用户定义的目标数量。不直接使用） 　　Deployment： （无状态，守护进程类，只关注群体不关注个体） 　　　　工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。（pod数量和node没有精确的配比，没有一对一的关系） 　　DaemonSet：（无状态，守护进程类，只关注群体不关注个体）

适用对象 使用 Alpine Linux 发行版的 Docker 镜像容器。 仅仅适用于 没有 安装 uclibc 的系统。 修改步骤 进入容器命令行 ＃ docker exec -it container_name /bin/sh 安装 timezone 数据包 ＃ apk add - U tzdata ＃ ls /usr /share /zoneinfo 为了防止添加失败，加上 -U 参数，更新仓储缓存。 列出安装的时区文件，验证是否下载成功。 拷贝需要的时区文件到 localtime ，国内需要的是 Asia/Shanghai ： ＃ cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime 验证时区 ＃ date Tue Jan 9 22 :53 :46 CST 2018 CST 即为 中国标准时间 。 移除时区文件： ＃ apk del tzdata 作者：mcjiffy 链接：https://www.jianshu.com/p/cd1636c94f9f 来源：简书 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 来源： oschina 链接： https://my.oschina.net/u/4395639/blog/4072918

好久不见 拖更王更新了，尴尬而不失礼貌的微笑 :) 感谢那些没有取关的朋友们！你们的坚持是对的！ 正文 出于各种原因，总会有需要编写时区转换代码的时候，好巧不巧的，最近我刚好在做一个需求的时候就需要做时区转换。 呵，真巧（不踩坑，哪来这篇文章...）。 准备工作 下面通过简单的十来行代码给大家做个演示，如果你把代码拷贝到你本地运行，我相信都能够正常运行的。 // main.go package main import ( "fmt" "time" ) func main () { now := time.Now() fmt.Printf( "Time: %v, Location: %v\n" , now, now.Location()) shanghai, err := time.LoadLocation( "Asia/Shanghai" ) if err != nil { panic (err) } shanghaiNow := now.In(shanghai) fmt.Printf( "Time: %v, Location: %v\n" , shanghaiNow, shanghaiNow) } 正常运行的话，你大概能看见如下输出： Time: 2020-10-26 18:32:34.63303 +0800 CST m=+0.000066515, Location: Local

1.使用maven将项目打成一个包含所有的jar包 2.pom.xml中包含即可通过mvn clean package 就可以打成可执行jar包 <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.3.2</version> <configuration> <source>1.8</source> <target>1.8</target> <encoding>UTF-8</encoding> </configuration> </plugin> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <fork>true</fork> <mainClass>com.org.Application</mainClass> <layout>ZIP</layout> </configuration> <executions> <execution> <goals> <goal>repackage</goal

Docker 是一个供软件开发人员和系统管理员使用容器构建、运行和与分享应用程序的平台。容器是在独立环境中运行的进程，它运行在自己的文件系统上，该文件系统是使用 docker 镜像构建的。镜像中包含运行应用程序所需的一切（编译后的代码、依赖项、库等等）。镜像使用 Dockerfile 文件定义。 术语 dockerization 或 containerization 通常用于定义创建 Docker 容器的过程。 因为容器具备如下优点，所以很受欢迎： 灵活性：即使是最复杂的应用程序也可以容器化。 轻量化：容器共享主机内核，使得它们远比虚拟机高效。 便携性：可以做到本地编译，到处运行。 松耦合：容器自我封装，一个容器被替换或升级不会打断别的容器。 安全性：容器对进程进行了严格的限制和隔离，而无需用户进行任何配置。 在这篇文章中，我将重点讨论如何优化 Docker 镜像以使其轻量化。 让我们从一个示例开始，在该示例中，我们构建了一个 React 应用程序并将其容器化。运行 npx 命令并创建 Dockerfile 之后，我们得到了如图 1 所示的文件结构。 npx create-react-app app --template typescript 图 1：文件结构 如果我们构建一个基础的 Dockerfile（如下所示），我们最终会得到一个 1.16 GB 的镜像： FROM node

该笔记将记录：在 Alpine Linux 中，APK 包管理器的常用设置及使用方法。 修改软件源（用于 Docker Image 构建） Alpine Linux 源使用帮助 sed -i 's%dl-cdn.alpinelinux.org%mirrors.ustc.edu.cn%g' '/etc/apk/repositories' 来源： oschina 链接： https://my.oschina.net/u/4948974/blog/4922399

使用 docker buildx 实现多平台编译 docker registry api v2 支持多 CPU 架构镜像. 同时 harbor v2 也实现了 docker registry api v2 的支持. 0x01 准备 docker 开启实验模式 buildx 插件 qemu 模拟器 Linux kernel >= 4.8 linux 系统内核 由于 binfmt_misc 机制开启需要依赖 Linux kernel >= 4.8 。 因此，在对 linux 系统操作选型上有一定要求。 建议使用 发行版 出场内核已经满足需求的操作系统。 而不是选择自己升级系统内核。 ubuntu:18.04 LTS 及以上 debian:10 及以上 参考文章: build multi architecture docker image with buildx 开启实验模式 当前 buildx 还是一个实验模式, 如需要支持, 需要进行如下配置 开启实验模式。 修改 /etc/docker/daemon.json , 增加 experimental 字段， 如下。 # vi /etc/docker/daemon.json { "experimental": true } 安装 buildx 将 buildx 放到 ~/.docker/cli-plugins/ 目录下 # https:/