Alpine Linux

今天，发布了.NET 5.0 Preview5。主要对它进行了一小部分新功能和性能的改进。 .NET 5.0 Preview 4 包含了一些计划和.NET 5.0要交付的内容。 现在，大多数的功能都已经包含在里面，但是有许多功能还未到最终状态。预计这个版本在Preview 7中完善。 可以下载适用于Windows，macOS和Linux的 .NET 5.0 Preview 5 ： Windows and macOS installers Binaries Docker images Snap installer ASP.NET Core 和 EF Core 也在今天发布了 我们需要使用Visual Studio 2019 16.7才能使用.NET 5.0。 安装最新版本的 C＃扩展 ，以将.NET 5.0与Visual Studio Code结合使用。 Mac的Visual Studio尚不支持.NET 5.0。 发布说明: .NET 5.0 release notes .NET 5.0 known issues GitHub release GitHub tracking issue RyuJIT改进 对RyuJIT JIT编译器进行了以下改进 新的、更快的、可移植的tailcall helper实现 。 ARM64硬件内部物理的实现进程 实现ASIMD Extract

　　前文我们聊了下docker的基础使用方法，大概介绍了下docker的架构，管理镜像、运行容器、管理容器的一些相关命令说明；回顾请参考 https://www.cnblogs.com/qiuhom-1874/p/12933412.html ；今天这边博客主要来聊docker的镜像的制作和分发，以及相关镜像的操作和说明； 　　前面我们提到过docker最核心资源之一就是镜像，镜像就好比是我们的应用程序，要想运行它，前提是要拥有它，并把它装载操作系统上；而docker里的镜像就是把应用程序所依赖的库、文件、环境等打包在一起，组成一个静态的镜像文件；这样一来有了这个镜像，我们就可以把我们自己的应用程序在任何有docker环境的主机上运行成容器；这也是docker受欢迎的原因之一吧，解脱了程序员为其应用程序而苦恼； 　　docker镜像包含了应用程序启动所需的文件系统以及内容，其目的就是为创建并启动为docker容器；那么docker的镜像到底是怎么构建的呢？我们来看看下面的图大概就会明白 　　提示：docker镜像采用分层构建的机制，最低层为bootfs，该层的主要作用是用于系统引导的文件系统，包括bootloader和内核，容器启动完成后会被卸载以节省内存资源；在bootfs之上的是rootfs，该层主要表现为docker容器的根文件系统；传统模式中，系统启动之时

在写Dockerfile时, ENV和ARG，包括.env都是很容易弄混的概念。让我们对其进行区分。 .env文件 和docker-compose.yml配合使用。并不和Dockerfile一起使用 env_file 在Dockerfile中使用，当环境变量很多，可食用该参数，指定对应的变量文件。 ARG 在Dockerfile中使用，仅仅在build docker image的过程中（包括CMD和ENTRYPOINT）有效，在image被创建和container启动之后，无效。 如果你在Dockerfile中使用了ARG但并未给定初始值，则在运行docker build的时候未指定该ARG变量，则会失败。 虽然其在container启动后不再生效，但是使用‘docker history’可以查看到。所以，敏感数据不建议使用ARG. 设置ARG和使用ARG编译image, 实例如下： # In the Dockerfile ARG some_variable_name # or with a hard-coded default: #ARG some_variable_name=default_value RUN echo "Oh dang look at that $some_variable_name" # In the shell command docker build -

镜像： php镜像： X.X-zts-alpine （和httpd整合在一块） mysql镜像： mysql:X.X 未完待续... 来源： oschina 链接： https://my.oschina.net/u/4280362/blog/4330174

前言 安装docker啥的就不说了，这里重点强调一下，docker的环境问题。本人的环境： 虚拟机centos => docker => NAT => container 因为需要不断更换网络环境，如若使用桥接，需要不断调整网卡的IP，使虚机与宿主机保持在同一网段，所以干脆用了NAT，此处需要明确一下。因为每个人跑docker的环境不一样，也就导致解决问题的方法不一定在每个环境下都灵验。所以网上很多千篇一律的方法就要慎重选择。 制作镜像时的注意事项，或坑点： 为了更稳定的网速，建议重新配置一下DNS，在国内的话最好切一下docker的源，国内比较稳定的有阿里，网易，中科大等，docker通过设置 /etc/docker/daemon.json ，添加对应的源字段即可。 { "dns": ["8.8.8.8", "114.114.114.114"], "registry-mirrors": ["http://f42ebfb9.m.daocloud.io"] } 其次，基于不同的基础镜像，使用的包管理工具也不尽相同，debian、ubuntu系： apt-get（基于dpkg），redhat、centos系：yum（基于rpm），alpine系： apk。这点新手可能比较迷惑。可翻阅我之前的linux文章。 自己在本地尝试使用 docker build 测试制作结果时

目录 用前端姿势玩docker【一】Docker通俗理解常用功能汇总与操作埋坑 用前端姿势玩docker【二】dockerfile定制镜像初体验 用前端姿势玩docker【三】基于nvm的前端环境构建技巧 用前端姿势玩docker【四】基于docker快速构建webpack的开发与生产环境 用前端姿势玩docker【五】快速构建中类Unix系统与Windows系统的差量化处理【待发布，请持续关注】 前言 关于docker构建前端环境，相关的坑点与难点，基本上都在这儿了，很多都是个人尝试总结的经验，都是从小白过来的，希望能帮助大家快速解决一些问题，抛开前端环境来看，差不多点的镜像基本也够用了。反而前端对易用性的要求更高（前端开发人员可不是天天跟linux打交道），还需要考虑类unix系统与windows的差异化问题，这点会在下一篇文章中重点说明。 打赏啥的也不需要，如果可以，很感激能在github上给个小星星，github入口在 博客最顶部 回顾 之前也说过 docker对于前端而言组重要的两个优势： 工作环境的快速构建 工作环境的统一 所以利用docker的工程化工作流在想象中应该是这样的： 例如一个新人从0到1构建前端环境： 安装docker => 拉取镜像 => 根据环境（dev、build）的不同传入不同的环境变量运行相应的容器 至此ok，易用性做到位之后

　　前文我们了解了下LXC的基础用法以及图形管理工具LXC WEB Panel的简单使用，有兴趣的朋友可以参考 https://www.cnblogs.com/qiuhom-1874/p/12904188.html ；今天这篇随笔主要是想把docker的相关的基础知识梳理一下； 　　一、docker和LXC 　　首先我们来说一下docker和传统LXC容器有什么不同。传统LXC是将内核的资源用名称空间的方式将其不同容器的资源，虚拟成多份；使得每个容器间的资源相互隔离；在前边我们也提到过LXC只是容器的一种客户端工具；真正实现容器的是内核功能；而docker和LXC没有本质的不同，都是容器的客户端工具；LXC是使用内核的功能将不同容器间的资源相互隔离，而docker是LXC上的另一种封装；LXC在创建容器时，依赖一个模板，而docker创建容器时，依赖镜像； 　　从上面的图可看出，LXC容器里跑了很多进程,而docker是一个容器跑一个进程，以及该进程的子进程；LXC更像是系统级容器，而docker更像是进程级容器或者说应用程序级容器； 　　在docker容器里通常只会有一个进程和该进程的子进程，通常该进程的进程编号为1，这也就说明了如果docker容器里进程编号为1的进程宕了，那么该容器也就随之宕掉；docker的镜像是采用的一种“分层构建，联合挂载”的方式实现

原文链接： Docker 容器优雅终止方案 作为一名系统重启工程师（SRE），你可能经常需要重启容器，毕竟 Kubernetes 的优势就是快速弹性伸缩和故障恢复，遇到问题先重启容器再说，几秒钟即可恢复，实在不行再重启系统，这就是系统重启工程师的杀手锏。然而现实并没有理论上那么美好，某些容器需要花费 10s 左右才能停止，这是为啥？有以下几种可能性： 容器中的进程没有收到 SIGTERM 信号。 容器中的进程收到了信号，但忽略了。 容器中应用的关闭时间确实就是这么长。 对于第 3 种可能性我们无能为力，本文主要解决 1 和 2。 如果要构建一个新的 Docker 镜像，肯定希望镜像越小越好，这样它的下载和启动速度都很快，一般我们都会选择一个瘦了身的操作系统（例如 Alpine ， Busybox 等）作为基础镜像。 问题就在这里，这些基础镜像的 init 系统 也被抹掉了，这就是问题的根源！ init 系统有以下几个特点： 它是系统的第一个进程，负责产生其他所有用户进程。 init 以守护进程方式存在，是所有其他进程的祖先。 它主要负责： 启动守护进程 回收孤儿进程 将操作系统信号转发给子进程 1. Docker 容器停止过程 对于容器来说， init 系统不是必须的，当你通过命令 docker stop mycontainer 来停止容器时，docker CLI 会将 TERM

执行删除前，先把该镜像运行的容器关掉，再删除容器，最后删除镜像，方可顺利进行 #关掉容器 docker stop 容器ID 　　 # 移除容器 docker rm 容器ID # 删除镜像 docker rmi 镜像ID（或）镜像标签 一、通过标签删除镜像 通过如下两个都可以删除镜像： docker rmi [image] 或者： docker image rm [image] 支持的子命令如下： -f, -force : 强制删除镜像，即便有容器引用该镜像； -no-prune : 不要删除未带标签的父镜像； Docker 查看镜像信息 例如，我们想删除上章节创建的 allen_mysql:5.7 镜像，命令如下： docker rmi allen_mysql:5.7 Docker 删除镜像 从上面章节中，我们知道 allen_mysql:5.7 和 docker.io/mysql:5.7 实际上指向的是同一个镜像，那么，您可以能会有疑问，我删除了 allen_mysql:5.7 , 会不会将 docker.io/mysql:5.7 镜像也给删除了？ 实际上，当同一个镜像拥有多个标签时，执行 docker rmi 命令，只是会删除了该镜像众多标签中，您指定的标签而已，并不会影响原始的那个镜像文件。 不信的话，我们可以执行 docker images 命令，来看下 docker.io

一. X86编译 1． 安装zeromq库 根据 setup script 安装： wget https: // github.com/zeromq/libzmq/releases/download/v4.2.2/zeromq-4.2.2.tar.gz tar xvzf zeromq- 4.2 . 2 .tar.gz cd zeromq - 4.2 . 2 . / configure sudo make install sudo ldconfig ldconfig -p | grep zmq libzmq.so. 5 (libc6,x86- 64 ) => /usr/local/lib/libzmq.so. 5 libzmq.so (libc6,x86 - 64 ) => /usr/local/lib/ libzmq.so export PKG_CONFIG_PATH =/usr/local/lib/pkgconfig/ 2． 获取源码 go get github.com/edgexfoundry/edgex-go 3． 安装依赖包 edgex0.7.1采用glide管理go工程 $ glide install [INFO] Lock file (glide. lock ) does not exist. Performing update. [INFO] Downloading