Docker容器是无状态的（不需要在运行时候做持久化数据）。一般来讲，一些有状态的，存储重要数据的应用需要一些持久存储。卷功能提供了一种支持此要求的方法，但它带有一些关于文件系统权限的问题。 在大多数部署的设置中，将使用容器编排机制，并且持久存储由某些公共云产品提供，这些产品可能具有自己的配置权限的方式。但是，在本地开发或产品的早期迭代期间，最简单的方法是将主机目录公开为docker卷。 简而言之

我们在github上，或者在一些应用官方提供的docker镜像的Dockerfile中，经常会看到很多难以琢磨的操作，这篇文章主要说明使用Dockerfile的RUN命令为什么要在后面使用&&链接，以及在实际镜像中的影响和区别。阅读本篇文章对Dockerfile的RUN命令和层有更深的认识，同时学会更好的缩减容器的镜像。 为了更好的演示RUN命令与层带来的差异，我们分为几个步骤来做

docker容器的应用程序易于部署管理是基于docker镜像，一个优良的docker镜像是非常有必要的。 在多数情况下，我们处于无状态应用的快速部署，这个过程中，且不管你在dockerhub使用还是本地镜像仓库使用，合理的镜像的大小也是有必要的。除此之外，我们应该考虑那些？ Docker镜像大小的重要性？ 网络带宽导致的空闲等待 除了镜像大小外，我们还需要考虑更新迭代的问题，更大的基础镜像意味着需

使用Docker Config而不是使用嵌入式配置创建镜像怎么样？ 在镜像中嵌入配置？ 我们经常看到Dockerfile如下所示，其中创建新镜像只是为了将配置添加到基本镜像。 $ cat Dockerfile FROM marksugar：redis:5.0.0 RUN curl http:/xx/x/xredis.conf -o /etc/redis/redis.conf 在上述中，是将最新的r

切勿将配置或机密信息嵌入Docker镜像中。相反，在构建Docker镜像时，期望使用业务流程运行时将配置和机密的信息提供给容器，这些包含：Kubernetes Secrets，Docker Secrets。而外部工具或环境变量（对于非敏感性）用于非敏感数据。但仍需注意，不要无意中在镜像层的隐藏层中包含机密信息。 概述 容器镜像应该是可重用且安全的。当镜像层包含嵌入式配置或机密信息时，它违反了此规则

在这篇文章中，我描述了在无法提供任何层缓存的无服务器主机上构建时，我如何提高容器的构建性能。我使用多阶段构建和远程存储库缓存的组合来避免重复性工作来提高性能。 阅读本篇，你将了解--target的使用和--cache-from的使用，更好理解多阶段构建和缓存的利用。我将会在文章末尾放置多阶段构建使用的本站链接 note 使用--target来构建多级建立的特定阶段，并推动这些镜像传输到远程存储库。

FOSSBilling 是免费的开源计费，旨在为客户和卖家提供方便。FOSSBilling 是 BoxBilling 的一个分支。它通过直观的界面为客户提供卓越的体验，并支持多种支付网关。FOSSBilling 适用于多种企业，从小型到中型甚至大型企业。FOSSBilling 可以帮助您自动化开具发票、收款以及客户管理和沟通。 在本指南中，我将在 Rocky Linux 9 服务器上安装 FOSS

一般情况下，我们仅仅需要修改容器的时间与我们宿主机的实际实际一致即可， 我们知道，默认情况下docker容器是不允许访问系统时钟，但是有一款开源的软件使这样的需求变成了可能。此lib拦截用于检索当前时间和日期的所有系统调用，完成了容器内时间的修改。 阅读此篇文章，你将了解在容器内修改时间的方法。 使用 以alpine为例，我们进行编译安装，并挑选几个简单的使用方法来进行演示这个时间调整 git c

Docker可以加速部署周期，可以更快速度推出代码。但它也带来了一系列意想不到的安全隐患，你应该知道。 下面是五种常见的场景，其中部署Docker镜像会打开以前可能没有考虑过的新类型的安全问题，以及一些好的工具和建议，你可以使用它们来确保在部署时尽可能的减少安全隐患。 1.镜像的真实性 让我们从一个Docker本质上固有的问题开始：镜像真实性。如果你已经使用Docker一段时间，你将熟悉很多镜像和

在此前的文章中有安装配置harbor，但是没有配置https，后来我发现在某一些时候，https还是挺有用的，于是就按照github上的参考，安装配置完成。 阅读此章，你将快速了解中文文档harbor的自签https的使用方式 由于Harbor未附带任何证书，因此默认情况下使用HTTP来对外提供请求。但是，强烈建议为任何生产环境启用安全性。Harbor有一个Nginx实例作为所有服务的反向代理，可

容器彻底改变了开发，打包和部署应用程序的方式。但是，暴露给容器的系统表面足够多，以至于很多安全人员并不建议使用。 越来越希望运行更多应用担任更多的角色，同时也出现不同的安全问题，这引发了对沙盒容器 - 容器的新兴趣，这些容器有助于在主机操作系统和容器内运行的应用程序之间提供安全的隔离边界。 为此，我们想介绍一种新型沙箱gVisor，它有助于为容器提供安全隔离，同时比虚拟机（VM）更轻量级。gVis

在此之前，我记录了很多章关于docker使用的基础，从安装到编写，其中还有一些常见的使用技巧，这其中还包括一些docker-compsoe的简单操作案例，其中有一些由于编写的时间太久，bug很多，但用来学习绰绰有余，但也仅供参考。 现在，我将所有的文章汇聚在一个页面中方便查看。 假如你是一个docker新手，没有太多时间，你不妨从本章入手学习，假如你想详细了解docker,那我推荐你查看我记录的白

通常我们在编排一个容器的时候，最简单的方式就是使用docker-compose，compose是简单的将docker run的命令进行组织起来。而在docker早期的产品里面compose被收购后是很重要的一个环节。 当我们run一个容器的时候，一般而言，我们关注她的网络，持久化，资源情况以rabbitmq为例，如下： 2.4 version: '2.4' services: rabbitmq:

一个项目的master节点down了之后kubelet起不来，由于是远古时期的项目，早期未作任何监控手段。因此也没有监控，没有文档，非常棘手经过查看，master节点的kubelet未启动，查看kubelet日志: failed to run Kubelet: unable to load bootstrap kubeconfig: stat /etc/kubernetes/bootstrap-k

我们有两个版本的内核节点，分别是两个批次的节点，安装了3.10.95和5.4.x的内核 在出现Readiness probe failed和Liveness probe failed是一次pod驱逐而后就发生的 查看事件 # kubectl get events --sort-by='.lastTimestamp' -n kube-system LAST SEEN TYPE REASON OBJE

简单的进行初始化 1，安装相同版本的docker,复制必要的镜像文件到node节点导入2，同步时间3，将桥接的IPv4流量传递到iptables的链 cat > /etc/sysctl.d/k8s.conf << EOF net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 n

Kubernetes需要确保在 Pod 中运行的 应用是健康的。一旦应用出现问题，kubelet作为守护进程会根据为 Pod 设置的重启策略(restartPolicy)重启 Pod。现在的问题是 k8s 如何检测不健康的应用程序？答案是通过Probes。 restartPolicy默认为：Always Liveness、Readiness 和 Startup 探针 Kubernetes有 3 种

通过减少误操作带来的问题和提高服务质量，Kubernetes liveness 和 readiness 探针可用于使服务更健壮和更有弹性。但是，如果不仔细实施这些探测器，它们可能会严重降低服务的整体操作，以至于让人们觉得没有它们会更好。 在本文中，将探讨在实现 Kubernetes 的 liveness 和 readiness 探针时如何避免使服务可靠性变差。虽然本文的重点是 Kubernetes

之前，我写过一篇Kubernetes Liveness 和 Readiness 探测避免给自己挖坑续集，描述了 Kubernetes 的 liveness 和 readiness 探针如何无意中降低服务可用性，或者导致长时间的中断。 Kubernetes liveness 和 readiness 探针是旨在提高服务可靠性和可用性的工具。但是，如果不考虑整个系统的动态，尤其是异常动态，你就有可能使服

Kubernetes liveness 和 readiness 探针可用于提高服务的可靠性。但是，如果不小心使用它们，它们可能会适得其反，并通过微妙的、意想不到的后果降低服务的可靠性。 我写了一个分别有几部分的文章(见延伸阅读)，介绍如何使用 Kubernetes 的 liveness 和 readiness 探针来避免“给自己挖坑”。我详述的一些问题与启动动态有关。Kubernetes 1.16