Category Archives: Docker

Docker 部署 Net Core

一、docker 安装及设置

#安装 CentOS已经将Docker软件包放在了Extras软件源中，直接利用即可

yum install docker-io -y

#查看docker的版本 version

docker -v

#开启Docker服务

systemctl start docker.service

#开机启动Docker服务

systemctl enable docker.service

#查看Docker服务启动状态

systemctl status docker.service

#重启Docker服务

systemctl restart docker.service

二、新建Net Core 程序 1、新建Net Core 项目。注意不启动Docker 支持 2、发布新建的项目（目标运行时：可移植） 3、在发布后的文件夹中新建一个Dockerfile 文件（没有后缀）大概内容如下：

FROM microsoft/dotnet:2.1-aspnetcore-runtime //注意和你的版本要匹配

WORKDIR /app

COPY . . //将当前目录下的所有文件（除了.dockerignore排除的路径），都拷贝进入 image 文件的/app目录。

EXPOSE 5000 //端口号（将容器 5000 端口暴露出来，允许外部连接这个端口。）

//EXPOSE 443 //Https 端口开启

ENTRYPOINT ["dotnet", "DockerDemo5.dll"] //运行的程序集改成你自己的

三、上传发布后的项目到Linux服务器（CentOS） 1、进入程序的发布目录

#进入到程序的发布目标

cd /data/web/mydocker

#创建 image文件（-t参数用来指定 image 文件的名字，后面还可以用冒号指定标签 PS：注意最后的点）

docker build -t aspnetcoredocker1.1 .

#生成容器，每运行一次，就会新建一个容器（这里的5000：5000 代表把容器内的5000端口映射到你主机的5000端口,容器端口在后）

docker run -it -p 5000:5000 aspnetcoredocker1.1

#docker run -it -p 5000:5000 aspnetcoredocker1.1:TAG // 默认TAG是latest

2、直接访问就可以了 3、docker 容器自动启动（在容器退出或断电开机后，docker可以通过在容器创建时的 --restart参数来指定重启策略）

# 设置启动策略

docker run --restart always -it -p 5000:5000 aspnetcoredocker1.1

#如果容器已经被创建，我们想要修改容器的重启策略

docker update --restart always 3ec28be7254a //容器ID

# --restart 多个参数值选择

no 不自动重启容器. (默认值)

on-failure 容器发生error而退出(容器退出状态不为0)重启容器,可以指定重启的最大次数，如：on-failure:10

unless-stopped 在容器已经stop掉或Docker stoped/restarted的时候才重启容器，手动stop的不算<br>always 在容器已经stop掉或Docker stoped/restarted的时候才重启容器

4、docker 相关命令镜像文件和容器命令

#查看所有镜像

docker images

#删除一个imageid的镜像

docker rmi [IMAE_ID]

#删除所有镜像

sudo docker rmi $(docker images -q)

#查看所有容器运行状态

docker ps -a

docker container ls -all

#删除一个containerid的容器(实例)

docker rm 6f0c67de4b72

#删除所有容器

docker rm $(sudo docker ps -a -q)

容器日志

#查看指定时间后的日志，只显示最后100行：

docker logs -f -t --since="2019-06-08" --tail=100 CONTAINER_ID

#查看某时间之后的日志：

docker logs -t --since="2019-06-08" CONTAINER_ID

#查看某时间段日志：

docker logs -t --since="2019-06-08" --until "2019-06-09" CONTAINER_ID

#查看最近30分钟的日志:

docker logs --since 30m CONTAINER_ID

from:https://www.cnblogs.com/songl/p/11128012.html

龙生 04 Sep 2020

View Details

Docker入门第一课 --.Net Core 使用Docker全程记录

微服务架构无疑是当前最火热的开发架构，而Docker作为微服务架构的首选工具，是我们必须要了解掌握的。我通过一天的时间，网上查文档，了解基础概念，安装Docker，试验Docker命令，通过Docker，成功部署运行Asp.NET core示例程序，算是基本入门。这篇文章是自己总结的Docker入门篇，力求简洁，快速入门，以最短的时间看到学习成果，为深入学习Docker做基础。学习前提：不要畏惧面对未知，人们心里往往会产生恐惧，这是人与生俱来的，所以，我们在进入新的领域之前，首先要克服的是自己的畏难心理。不要因为困难，看几眼就放弃，那样你永远学不会。面对新的未知领域，我们要把它当成一座灯塔，让它指引我们前进的方向。第一：了解几个概念镜像（Image）：相信大家看到这个词，都明白什么意思，我们可以把它理解为操作系统的安装盘，Ghost镜像。我给它个定义，就叫：Docker基础运行环境副本。容器（Container）：运行中的Docker实例，称为容器。也就是一个镜像（Image）的运行时状态。镜像仓库（Repository）：Docker为开发者提供了面向各种环境的已经打包好的镜像，这些镜像构成了一个镜像仓库。开发者只需找到自己需要的Docker镜像，下载到本地，添加自己的应用上去，运行即可，某些工具类的镜像，可无需修改，直接运行。 Docker 主机（Host）：运行着Docker容器的计算机或虚拟机，用于执行Docker的守护进程。 Docker客户端（Client）：是与Docker主机守护进程进行通信的工具，如：Docker控制台。第二：安装Docker 不同操作系统按照方式不同，以Win7系统为例，需要利用 docker toolbox 来安装，可以使用阿里云的镜像来下载。下载地址：http://mirrors.aliyun.com/docker-toolbox/windows/docker-toolbox/ 安装完成之后，在桌面找到三个启动图标：Oracle VM VirtualBox，Kitematic(Alpha)，Docker Quickstart …。安装完成之后，建议重启一下计算机。 Oracle VM VirtualBox ：是一个虚拟机程序。Docker是运行在Linux环境下的，要想在Windows下运行，必须借助虚拟机。感兴趣的话可以留着以后研究。 kitematic（alpha）：是docker推出的GUI工具，可以更简便地操作Docker，非常适合windows用户使用习惯，推荐大家试试。这个alpha表示预览版吧，可能功能还不完善。 Docker Quickstart Terminal：是Docker控制台启动程序，双击图标启动Docker。如果一切正常的话，可以看到以下界面。如果启动过程中出现下面错误，Looks like something went wrong in step 'Looking for vboxmanage.exe’… 意思是没有找到虚拟机启动程序，需要设置VirtualBox的环境变量，系统环境变量中增加VBOX_MSI_INSTALL_PATH和VBOX_INSTALL_PATH 值都为C:\Program Files\Oracle\VirtualBox\ ，即VirtualBox的安装路径，注意后面的\ 不能少。环境变量设置完成之后，可尝试重新启动。第三：熟悉几个命令我建议实际工作中使用图形界面 kitematic，真的既简单又实用，但Docker命令还是要学习的，最重要的是，使用命令行操作显得更酷更专业。 docker 命令都是以docker开头，下面介绍几个简单，常用的命令。仅作基础介绍，具体参数用法可后期详细学习。 docker pull：从镜像仓库中拉取镜像。 docker run：通过镜像创建一个新的容器，并运行。需要注意的是，如果本地没有指定的镜像，会直接去镜像库下载，一定要保证拼写正确。 docker stop：停止一个容器。 docker start：启动一个容器。 docker restart：重启一个容器。 docker ps：列出当前运行的容器机器状态。 docker images 或 docker image ls：列出本地镜像。 docker build：使用Dockerfile创建自己的镜像。第四：操作演示，从hello world开始你可以登录Docker官方镜像仓库，选择自己感兴趣的镜像进行试验，这里我们选择最简单的 hello-world。 Docker官方镜像仓库地址：https://hub.docker.com […]

龙生 04 Sep 2020

View Details

什么是CI/CD

CI, CD AND CD 当我们在谈论现代的软件编译和发布流程的时候，经常会听到CI 和CD这样的缩写短语。CI很容易理解，就是持续集成。但是CD既可以指代码持续交付，也可理解为代码持续部署。CI和CD之间有很多相似的部分，但是也有很大的区别。这里我们将给大家介绍它们之间的区别和联系。持续集成（CONTINUOUS INTEGRATION）在持续集成环境中，开发人员将会频繁的提交代码到主干。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证。这样做是基于之前持续集成过程中很重视自动化测试验证结果，以保障所有的提交在合并主线之后的质量问题，对可能出现的一些问题进行预警。持续交付（CONTINUOUS DELIVERY）持续交付就是讲我们的应用发布出去的过程。这个过程可以确保我们尽可能快的实现交付。这就意味着除了自动化测试，我们还需要有自动化的发布流，以及通过一个按键就可以随时随地实现应用的部署上线。通过持续交付，您可以决定每天，每周，每两周发布一次，这完全可以根据自己的业务进行设置。但是，如果您真的希望体验持续交付的优势，就需要先进行小批量发布，尽快部署到生产线，以便在出现问题时方便进行故障排除。持续部署（CONTINUOUS DEPLOYMENT）如果我们想更加深入一步的话，就是持续部署了。通过这个方式，任何修改通过了所有已有的工作流就会直接和客户见面。没有人为干预（没有一键部署按钮），只有当一个修改在工作流中构建失败才能阻止它部署到产品线。持续部署是一个很优秀的方式，可以加速与客户的反馈循环，但是会给团队带来压力，因为不再有“发布日”了。开发人员可以专注于构建软件，他们看到他们的修改在他们完成工作后几分钟就上线了。基本上，当开发人员在主分支中合并一个提交时，这个分支将被构建、测试，如果一切顺利，则部署到生产环境中。合并CI CD and CD？当然，正如我所说，他们每部分都更加接近生产环境。你可以构建自己的持续集成环境，然后，一旦团队适应，你可以添加持续交付流，最后，可以添加持续部署流到整个工作流中。举例CI, CD and CD 流水线到底值不值这样做呢? 持续集成: 你需要具备哪些条件: 你的团队需要为每个新功能，代码改进，或者问题修复创建自动化测试用例。你需要一个持续集成服务器，它可以监控代码提交情况，对每个新的提交进行自动化测试。研发团队需要尽可能快的提交代码，至少每天一次提交。你能获得什么呢？: 通过自动化测试可以提早拿到回归测试的结果，避免将一些问题提交到交付生产中发布编译将会更加容易，因为合并之初已经将所有问题都规避了减少工作问题切换，研发可以很快获得构建失败的消息，在开始下一个任务之前就可以很快解决。测试成本大幅降低-你的CI服务器可以在几秒钟之内运行上百条测试。你的QA团队花费在测试上面的时间会大幅缩短，将会更加侧重于质量文化的提升上面。持续交付需要具备什么条件？: 你需要有强大的持续集成组件和足够多的测试项可以满足你代码的需求部署需要自动化。触发是手动的，但是部署一旦开始，就不能人为干预。你的团队可能需要接受特性开关，没有完成的功能模块不会影响到线上产品。你能收获什么？: 繁琐的部署工作没有了。你的团队不在需要花费几天的时间去准备一个发布。你可以更快的进行交付，这样就加快了与客户之间的反馈环。轻松应对小变更，加速迭代持续部署需要具备的条件: 研发团队测试理念比较完善。测试单元的健壮性直接决定你的交付质量。你的文档和部署频率要保持一致。特征标志成为发布重大变化过程的固有部分，以确保您可以与其他部门（支持，市场营销，公关…）协调。可以获得什么？: 发布频率更快，因为你不需要停下来等待发布。每一处提交都会自动触发发布流。在小批量发布的时候，风险降低了，发现问题也可以很轻松的修复。客户每天都可以看到我们的持续改进和提升，而不是每个月或者每季度，或者每年。如前所述，您可以采用持续集成，持续交付和持续部署。你怎么做取决于你的需求和你的业务情况。如果你刚刚开始一个项目，并且还没有客户，那么你就可以去创建这些工作流，最好是将这三个方面都实现，并且在你的项目迭代和需求增长中同时迭代它们。如果您已经有一个生产项目，那么您可以一步一步地分阶段去实现他们。原文链接：http://www.ttlsa.com/news/ci-cd-cd/ from:https://www.cnblogs.com/soymilk2019/p/11445773.html

龙生 19 May 2020

View Details

CD基金会、Jenkins、Jenkins X、Spinnaker和Tekton的常问问题

FAQ 什么是持续交付（CD）？ CD是一种软件工程方法，团队在短周期内生成软件，确保软件可以随时可靠地发布。微服务、云原生架构的兴起引发了持续交付实践的必然结果。这与CI/CD有关，其中包括持续集成（CI） – 将所有开发者工作副本一天多次合并到共享主线的做法。宣布了什么？ CDF（Continuous Delivery Foundation，持续交付基金会）是一个新的、中立的组织，将发展和维持一个开放的持续交付生态系统。它将提供统一的治理和与供应商中立的管理，以及对资金和运营的监督。CD基金会的第一批项目是Jenkins、Jenkins X、Spinnaker和Tekton。为什么CD社区组成基金会。为什么需要？整个行业都迫切需要围绕管道、工作流程和其他CI/CD领域合作定义行业规范，并为CI/CD工具提供基础支持。例如，Jenkins社区正在寻求一个“全方位服务”的基金会来托管Jenkins（最受欢迎的CI/CD项目之一），并构建一个增强协作的平台。还需要一个全行业的中立DevOps/CD会议。这是否代表了云原生态系统的转变？是的，市场已转向容器化和云原生技术，因此CI/CD系统、DevOps和相关工具的生态系统发生了根本性的变化。CNCF云原生互动景观展示了CI/CD领域的多样性，以及在该领域中活跃的众多项目和供应商。通过建立供应商中立的持续交付基金会，业界顶级开发者、最终用户和供应商可以将CI/CD作为方法，定义/记录最佳实践以及创建培训材料，以使全球任何软件开发团队能够交付代码更改更快、更可靠、无论它们是否为云原生。开发者为何要关心？ CI/CD项目目前面临的挑战，包括工具复杂性和管道和其他CI/CD工具缺乏行业标准化，正在抑制增长和创新。由于缺乏中立的法律实体和强有力的治理，项目很难吸引新开发者和组织的宝贵支持。项目维护者和开发者花费大量时间和金钱处理安全程序和监督等方面的变通方法。这使人们不再关注新的发展和创新。拥有广泛行业支持的基金会将能够更快地定义行业规范，并为跨项目协作创造更多机会，以改善开发者的工具。谁用CD？ CD广泛应用于云计算、企业IT，并且正在迅速扩展到其他顶级行业垂直领域。例如，在网络运营商与供应商并肩工作，开发CI/CD工具，使开发者能够直接与上游项目的分支合作 – 大幅缩短实施新功能的时间，并解决数月到数天的错误。使用云原生技术（如Kubernetes）时，设置CI/CD管道将加快发布生命周期。这使开发者每天可以多次发布；让团队灵活到足以快速迭代。 CDF如何与渐进式交付相关？渐进式交付（Progressive delivery）是现代持续交付技术的一种形式，例如灰度发布、功能标记、A/B测试、经过验证的部署组等。渐进式交付技术和技术与持续交付密切相关。有关渐进式交付的更多信息，请阅读James Governor关于此主题的Redmonk博客：https://redmonk.com/jgovernor… 这将如何影响开源软件的开发？持续交付可提高软件开发团队的速度、生产力和可持续性。CDF促进行业顶级开发者、最终用户和供应商之间的合作，以确保CD方法的软件工程充分发挥其潜力，推进开源软件开发。哪些项目将包含在CDF中？ CDF正在推出四个项目：Jenkins、Jenkins X、Spinnaker和Tekton，还有更多感兴趣的项目正在筹备中。我们邀请人们关注CDF技术监督委员会（“TOC”），该委员会将在未来做出项目决策：https://github.com/cdfoundati…。我是否必须是成员才可以贡献到CDF项目？绝对不是，CDF中的开源项目或任何Linux基金会计划的技术贡献都不需要成员资格。组织作为成员加入CDF，因为它们希望在持续交付模型和最佳实践的增长和发展中扮演积极的角色，而不只是支持CDF中的开放源码项目。如果你有兴趣加入，请参阅https://cd.foundation/members…。什么是Jenkins？ Jenkins是领先的开源自动化服务器，由大量不断增长的开发者、测试者、设计者和其他对持续集成、持续交付和现代软件交付实践感兴趣的人提供支持。它基于Java虚拟机（JVM），提供超过1,500个插件，可将Jenkins扩展为几乎所有技术软件交付团队使用的自动化服务器。2019年，Jenkins有超过了200,000个已知安装，使其成为部署最广泛的自动化服务器。什么是Jenkins X？ Jenkins X是Kubernetes上现代云应用程序的开源CI/CD解决方案。Jenkins X提供管道自动化、内置GitOps和预览环境，以帮助团队协作并加速他们的软件交付。Jenkins X使用最好的OSS工具自动化Kubernetes的CI + CD，如Jenkins、Tekton、Prow、SkaffoldKaniko和Helm。为什么Jenkins和Jenkins X成为CDF的一员？ Jenkins和Jenkins X将成为与技术兴趣相关的中立社区的一部分，并在构建开发者社区和项目治理方面获得帮助。CD基金会还将协助Jenkins和Jenkins X的营销和文档工作。这对现有Jenkins用户有何影响？将Jenkins和Jenkins X捐赠给CD基金会将促进行业内开发者、最终用户和供应商之间的更多合作。有关详细信息，请参阅此电子邮件和与Jenkins社区的对话：https://groups.google.com/for… 什么是Tekton？ Tekton是一组用于构建CI/CD系统的共享开源组件。它使持续交付控制平面现代化，并将软件部署的大脑转移到Kubernetes。Tekton的目标是通过供应商中立的开源基金会为CI/CD管道、工作流程和其他构建模块提供行业规范。Tekton的代码在https://github.com/tektoncd/p…。为什么Tekton成为CDF的一员？为什么Google会捐赠代码？作为CDF的创始成员，谷歌正在捐赠Tekton。正如Kubernetes通过提供一组标准的API在云中进行交互而彻底改变了应用程序开发，Google的目标是通过CD基金会为DevOps从业者提供相同的优势。CDF将提供行业规范、安全、实用和可扩展的持续交付构建块，可用于在任何地方部署代码。 Tekton对knative build的影响是什么？从第1天开始，可插拔性一直是knative的核心功能。将Build与Serving分离的目标是强化这种可插拔性概念。已经对构建系统感到满意的用户可以将其与Knative Serving一起使用。Tekton将继续支持Knative生态系统作为一流的目标环境。Tekton管道将部署到Knative环境。在可预见的未来，Knative Build将继续作为Knative的一部分，专注于无服务器环境的源到容器工作流程。这两个项目将在标准和界面上保持紧密联系。什么是Spinnaker？ Spinnaker是云端优先的持续交付平台，最初由Netflix创建，目前由Netflix和Google共同领导。它支持所有主要的云平台和Kubernetes，并得到各个供应商的贡献。Spinnaker通常用于大规模组织，DevOps团队通过提供“黄金路径”（golden path）应用程序部署管道来支持许多开发者。为什么Google/Netflix将Spinnaker捐赠给CDF？随着Spinnaker最近将其治理正式化，将其转移到基金会是社区自然的下一步。Spinnaker设计为持续交付平台，通常与Jenkins结合使用，因此CDF真的是项目的理想之家。 Spinnaker也是一个多组件系统，在概念上与Tekton分享了许多想法 – 看到两个项目在一个基金会上聚集在一起，是将持续交付向前推进的巨大机会。这对Spinnaker用户有何影响？ Spinnaker作为CDF的一员，社区将有更多机会创建更简单、更强大的端到端体验，并就CI/CD的一套通用标准进行协作。Spinnaker用户在持续交付领域拥有丰富的经验，加入CDF提供了一个与更广泛的社区分享专业知识的绝佳机会。 Spinnaker用户还将受益于CDF社区中广泛的CI/CD知识，他们使用的各种工具之间的一致性，当然还有不断改进的生态系统！未来的CI/CD项目进入CDF的过程是怎样？其他项目预计将通过其即将成立的技术监督委员会（TOC）加入CDF：https://github.com/cdfoundati…，重点是将CD生态系统整合在一起，围绕可移植性和互操作性构建规范和项目。 CDF的下一步是什么？接下来的步骤是启动治理结构。将成立一个理事会、技术和外联/营销委员会。我们计划在未来几个月内实现这一目标，并邀请新成员加入我们的社区。如果你有兴趣加入社区推进CD，请到https://cd.foundation/members…。 CNCF的参与程度，为什么需要一个单独的基金会？首先要注意的是，CD适用于整个软件行业，而不仅仅适用于现代云原生应用程序。CNCF（Cloud Native Computing Foundation，云计算本地计算基金会）是CDF的姐妹基金会，拥有自己的治理结构和使命。每个基金会都有不同的使命，由其创始成员和技术专家定义。CNCF认为大多数与CD相关的工具超出了他们专注的云原生定义的范围，后者主要关注容器化、微服务、服务网格和编排。CDF超越云和容器，包括传统基础设施、移动、物联网、裸机等。CNCF和CDF都属于较大的Linux基金会旗下，计划在许多领域进行合作，包括同场会议。例如，CDF将于5月20日在西班牙巴塞罗那的KubeCon + CloudNativeCon Europe 2019举办持续交付峰会（CDS）活动。 CDF如何支持或与DevOps领域的其他玩家合作？ CDF的使命是为开发者、最终用户和供应商提供一个中立的家庭，以便在CI/CD方法上进行协作。在这方面，CDF将通过发布关注可移植性的最佳实践、培训材料和行业指南来支持DevOps从业者。有兴趣成为这个新基金会成员并制定治理方案的组织应到CDF加入的页面。开发者可以在此处注册CD基金会邮件列表：info@lists.cd.foundation。任何有兴趣加入CDF的项目都可以联系技术监督委员会（TOC）：https://github.com/cdfoundati…。 KubeCon […]

龙生 12 Nov 2019

View Details

CentOS7安装k8s

借鉴博客：https://www.cnblogs.com/xkops/p/6169034.html 此博客里面有每个k8s配置文件的注释：https://blog.csdn.net/qq_35904833/article/details/78190257 啊西吧，啊西吧，根据上面的博客终于安装成功了。妈的，网上大部分博客安装k8s配置写得乱七八槽的，终于找到一篇条理清晰，安装详细的k8s安装博客啦，哈哈哈哈，不容易啊快三个星期了，从狗屁不懂搞这玩意。下面写一写我自己的安装流程：　　一、安装准备：准备两台服务器（我用的是CentOS7系统）：192.168.26.227，192.168.26.228 一主一从： master机：192.168.26.227 node机：192.168.26.228 简单说一下k8s：　　　　　　　　k8s是个什么玩意？可以这样去理解：k8s全称：Kubernetes，它可以看作是一个分布式系统支撑平台。　　　　　　　　我们为什么要用k8s集群？故障自愈： k8s这个玩意可以监控容器运行，我们把项目放到容器里。由于一些外部内部原因服务器承受不住压力，如果主节点上的容器突然挂了，k8s立刻会自己将主机上的服务调度到另一个node机器上运行应用更新：更新项目上线时不用中断当前项目的运行。还有一些自动扩容，缩容的概念就不讲了，我本人也没亲身体会用过，不好说。　　　　　　k8s的全生命周期管理：在k8s进行管理应用的时候，基本步骤是：创建集群，部署应用，发布应用，扩展应用，更新应用。　　　　　　k8s的主要组件，以及它们主要是用来干什么的： etcd：一款开源软件。提供可靠的分布式数据存储服务，用于持久化存储K8s集群的配置和状态 apiservice：用户程序（如kubectl）、K8s其它组件之间通信的接口。K8s其它组件之间不直接通信，而是通过API server通信的。这一点在上图的连接中可以体现，例如，只有API server连接了etcd，即其它组件更新K8s集群的状态时，只能通过API server读写etcd中的数据。 Scheduler：排程组件，为用户应用的每一可部署组件分配工作结点。 controller-manager：执行集群级别的功能，如复制组件、追踪工作结点状态、处理结点失败等。Controller Manager组件是由多个控制器组成的，其中很多控制器是按K8s的资源类型划分的，如Replication Manager（管理ReplicationController 资源），ReplicaSet Controller，PersistentVolume controller。 kube-proxy：在应用组件间负载均衡网络流量。 kubelet：管理工作结点上的容器。 Contriner runtime Docker， rkt等实际运行容器的组件上面都是些k8s集群所要用到的组件，具体这些组件都是用来干嘛的呢，我们来好好分析分析。 master主机上192.168.26.277必须要有的组件： etcd　　：提供分布式数据存储的数据库吧，用于持久化存储k8s集群的配置和状态 kube-apiserver：api service提供了http rest接口，是整个集群的入口，K8s其它组件之间不直接通信，而是通过API server通信的。（只有API server连接了etcd，即其它组件更新K8s集群的状态时，只能通过API server读写etcd中的数据） kube-scheduler：scheduler负责资源的调度 kube-controller-manager：整个集群的管理控制中心，此组件里面是由多个控制器组成的，如：Replication Manager（管理ReplicationController 资源），ReplicaSet Controller，PersistentVolume controller。主要作用用来复制组件、追踪工作结点状态、处理失败结点 node节点机上192.168.26.228必须要有的组件： flannel：好像是用来支持网络通信的吧 kube-proxy：用来负载均衡网络流量 kubelet：用来管理node节点机上的容器 docker：运行项目镜像容器的组件 2018年11月30日：今天又看了一些博客，多了一些认识和理解，如下：　　　　　　　　k8s的整个集群运行原理：【重点核心知识很重要】 master主机上的kube-controller-manager是整个集群的控制管理中心，kube-controler-manager中的node controller模块通过apiservice提供的监听接口，实时监控node机的状态信息。当某个node机器宕机，controller-manager就会及时排除故障并自动修复。 node节点机上的kubelet进程每隔一段时间周期就会调用一次apiservice接口报告自身状态，apiservice接口接受到这些信息后将节点状态更新到ectd中。kubelet也通过apiservice的监听接口监听pod信息，如果监控到新的pod副本被调度绑定到本节点，则执行pod对应的容器的创建和启动，如果监听到pod对象被删除，则删除本节点对应的pod容器。（目前对pod、容器、镜像这些概念还不是很清晰，无法在大脑中构建这都是些什么玩意，先做个笔记记着吧） […]

龙生 15 Aug 2019

View Details

Centos7 下Kubernetes集群安装部署

操作环境网络拓扑图、操作环境： k8s-master： OS：

1 2	[root@k8s-master ~]# cat /etc/redhat-release CentOS Linux release 7.4.1708 (Core)

etcd：

[root@k8s-master ~]# etcd --version

etcd Version: 3.2.9

Git SHA: f1d7dd8

Go Version: go1.8.3

Go OS/Arch: linux/amd64

Kubernetes：

[root@k8s-master ~]# kubectl version

Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"269f928217957e7126dc87e6adfa82242bfe5b1e", GitTreeState:"clean", BuildDate:"2017-07-03T15:31:10Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}

Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"269f928217957e7126dc87e6adfa82242bfe5b1e", GitTreeState:"clean", BuildDate:"2017-07-03T15:31:10Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}

k8s-node1&k8s-node2： OS：

1 2	[root@k8s-node1 ~]# cat /etc/redhat-release CentOS Linux release 7.4.1708 (Core)

etcd：

[root@k8s-node1 ~]# etcd --version

etcd Version: 3.2.9

Git SHA: f1d7dd8

Go Version: go1.8.3

Go OS/Arch: linux/amd64

docker：

[root@k8s-node1 ~]# docker version

Client:

Version: 1.12.6

API version: 1.24

Package version: docker-1.12.6-68.gitec8512b.el7.centos.x86_64

Go version: go1.8.3

Git commit: ec8512b/1.12.6

Built: Mon Dec 11 16:08:42 2017

OS/Arch: linux/amd64

Server:

Version: 1.12.6

API version: 1.24

Package version: docker-1.12.6-68.gitec8512b.el7.centos.x86_64

Go version: go1.8.3

Git commit: ec8512b/1.12.6

Built: Mon Dec 11 16:08:42 2017

OS/Arch: linux/amd64

Kubernetes：

1 2	[root@k8s-node1 ~]# kubectl version Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"269f928217957e7126dc87e6adfa82242bfe5b1e", GitTreeState:"clean", BuildDate:"2017-07-03T15:31:10Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}

安装部署安装前准备在安装部署集群前，先将三台服务器的时间通过NTP进行同步，否则，在后面的运行中可能会提示错误

1	[root@k8s-node1 ~]# ntpdate -u cn.pool.ntp.org

在node节点上安装redhat-ca.crt

1	[root@k8s-node1 ~]# yum install rhsm -y

etcd集群配置 master节点配置 1.安装kubernetes etcd

1	[root@k8s-master ~]# yum -y install kubernetes-master etcd

2.配置etcd选项 ETCD_DATA_DIR/ETCD_LISTEN_PEER_URLS/ETCD_LISTEN_CLIENT_URLS/ETCD_MAX_SNAPSHOTS/ETCD_NAME/ETCD_INITIAL_ADVERTISE_PEERURLS/ETCD_ADVERTISE_CLIENT_URLS/ETCD_INITIAL_CLUSTER

[root@k8s-master ~]# vi /etc/etcd/etcd.conf

#[Member]

#ETCD_CORS=""

ETCD_DATA_DIR="/var/lib/etcd/default.etcd"

#ETCD_WAL_DIR=""

ETCD_LISTEN_PEER_URLS="http://10.10.200.224:2380"

ETCD_LISTEN_CLIENT_URLS="http://10.10.200.224:2379,http://127.0.0.1:2379"

ETCD_MAX_SNAPSHOTS="5"

#ETCD_MAX_WALS="5"

ETCD_NAME="etcd1"

#ETCD_SNAPSHOT_COUNT="100000"

#ETCD_HEARTBEAT_INTERVAL="100"

#ETCD_ELECTION_TIMEOUT="1000"

#ETCD_QUOTA_BACKEND_BYTES="0"

#[Clustering]

ETCD_INITIAL_ADVERTISE_PEER_URLS="http://10.10.200.224:2380"

ETCD_ADVERTISE_CLIENT_URLS="http://10.10.200.224:2379"

#ETCD_DISCOVERY=""

#ETCD_DISCOVERY_FALLBACK="proxy"

#ETCD_DISCOVERY_PROXY=""

#ETCD_DISCOVERY_SRV=""

ETCD_INITIAL_CLUSTER="etcd1=http://10.10.200.224:2380,etcd2=http://10.10.200.229:2380,etcd3=http://10.10.200.230:2380"

#ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"

#ETCD_INITIAL_CLUSTER_STATE="new"

#ETCD_STRICT_RECONFIG_CHECK="true"

#ETCD_ENABLE_V2="true"

#[Proxy]

#ETCD_PROXY="off"

#ETCD_PROXY_FAILURE_WAIT="5000"

#ETCD_PROXY_REFRESH_INTERVAL="30000"

#ETCD_PROXY_DIAL_TIMEOUT="1000"

#ETCD_PROXY_WRITE_TIMEOUT="5000"

#ETCD_PROXY_READ_TIMEOUT="0"

#[Security]

#ETCD_CERT_FILE=""

#ETCD_KEY_FILE=""

#ETCD_CLIENT_CERT_AUTH="false"

#ETCD_TRUSTED_CA_FILE=""

#ETCD_AUTO_TLS="false"

#ETCD_PEER_CERT_FILE=""

#ETCD_PEER_KEY_FILE=""

#ETCD_PEER_CLIENT_CERT_AUTH="false"

#ETCD_PEER_TRUSTED_CA_FILE=""

#ETCD_PEER_AUTO_TLS="false"

#[Logging]

#ETCD_DEBUG="false"

#ETCD_LOG_PACKAGE_LEVELS=""

#ETCD_LOG_OUTPUT="default"

#[Unsafe]

#ETCD_FORCE_NEW_CLUSTER="false"

#[Version]

#ETCD_VERSION="false"

#ETCD_AUTO_COMPACTION_RETENTION="0"

#[Profiling]

#ETCD_ENABLE_PPROF="false"

#ETCD_METRICS="basic"

#[Auth]

#ETCD_AUTH_TOKEN="simple"

nodes节点配置 1.安装部署kubernetes-node/etcd/flannel/docker

1	[root@k8s-node1 ~]# yum -y install kubernetes-node etcd flannel docker

2.分别配置etcd，node1与node2的配置方法相同，以node1配置文件为例说明

[root@k8s-node1 ~]# vi /etc/etcd/etcd.conf

#[Member]

#ETCD_CORS=""

ETCD_DATA_DIR="/var/lib/etcd/default.etcd"

#ETCD_WAL_DIR=""

ETCD_LISTEN_PEER_URLS="http://10.10.200.229:2380"

ETCD_LISTEN_CLIENT_URLS="http://10.10.200.229:2379,http://127.0.0.1:2379"

#ETCD_MAX_SNAPSHOTS="5"

#ETCD_MAX_WALS="5"

ETCD_NAME="etcd2"

#ETCD_SNAPSHOT_COUNT="100000"

#ETCD_HEARTBEAT_INTERVAL="100"

#ETCD_ELECTION_TIMEOUT="1000"

#ETCD_QUOTA_BACKEND_BYTES="0"

#[Clustering]

ETCD_INITIAL_ADVERTISE_PEER_URLS="http://10.10.200.229:2380"

ETCD_ADVERTISE_CLIENT_URLS="http://10.10.200.229:2379"

#ETCD_DISCOVERY=""

#ETCD_DISCOVERY_FALLBACK="proxy"

#ETCD_DISCOVERY_PROXY=""

#ETCD_DISCOVERY_SRV=""

#ETCD_INITIAL_CLUSTER="default=http://localhost:2380"

#ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"

"/etc/etcd/etcd.conf" 66L, 1696C

#[Member]

#ETCD_CORS=""

ETCD_DATA_DIR="/var/lib/etcd/default.etcd"

#ETCD_WAL_DIR=""

ETCD_LISTEN_PEER_URLS="http://10.10.200.229:2380"

ETCD_LISTEN_CLIENT_URLS="http://10.10.200.229:2379,http://127.0.0.1:2379"

#ETCD_MAX_SNAPSHOTS="5"

#ETCD_MAX_WALS="5"

ETCD_NAME="etcd2"

#ETCD_SNAPSHOT_COUNT="100000"

#ETCD_HEARTBEAT_INTERVAL="100"

#ETCD_ELECTION_TIMEOUT="1000"

#ETCD_QUOTA_BACKEND_BYTES="0"

#[Clustering]

ETCD_INITIAL_ADVERTISE_PEER_URLS="http://10.10.200.229:2380"

ETCD_ADVERTISE_CLIENT_URLS="http://10.10.200.229:2379"

#ETCD_DISCOVERY=""

#ETCD_DISCOVERY_FALLBACK="proxy"

#ETCD_DISCOVERY_PROXY=""

#ETCD_DISCOVERY_SRV=""

#ETCD_INITIAL_CLUSTER="default=http://localhost:2380"

#ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"

#ETCD_INITIAL_CLUSTER_STATE="new"

#ETCD_STRICT_RECONFIG_CHECK="true"

#ETCD_ENABLE_V2="true"

ETCD_INITIAL_CLUSTER="etcd1=http://10.10.200.224:2380,etcd2=http://10.10.200.229:2380,etcd3=http://10.10.200.230:2380"

#[Proxy]

#ETCD_PROXY="off"

#ETCD_PROXY_FAILURE_WAIT="5000"

#ETCD_PROXY_REFRESH_INTERVAL="30000"

#ETCD_PROXY_DIAL_TIMEOUT="1000"

#ETCD_PROXY_WRITE_TIMEOUT="5000"

#ETCD_PROXY_READ_TIMEOUT="0"

#[Security]

#ETCD_CERT_FILE=""

#ETCD_KEY_FILE=""

#ETCD_CLIENT_CERT_AUTH="false"

#ETCD_TRUSTED_CA_FILE=""

#ETCD_AUTO_TLS="false"

#ETCD_PEER_CERT_FILE=""

#ETCD_PEER_KEY_FILE=""

#ETCD_PEER_CLIENT_CERT_AUTH="false"

#ETCD_PEER_TRUSTED_CA_FILE=""

#ETCD_PEER_AUTO_TLS="false"

#[Logging]

#ETCD_DEBUG="false"

#ETCD_LOG_PACKAGE_LEVELS=""

#ETCD_LOG_OUTPUT="default"

#[Unsafe]

#ETCD_FORCE_NEW_CLUSTER="false"

#[Version]

#ETCD_VERSION="false"

#ETCD_AUTO_COMPACTION_RETENTION="0"

#[Profiling]

#ETCD_ENABLE_PPROF="false"

#ETCD_METRICS="basic"

#[Auth]

#ETCD_AUTH_TOKEN="simple"

启动etcd cluster 分别在3台服务器启动etcd

[root@k8s-master ~]# systemctl start etcd.service

[root@k8s-master ~]# systemctl status etcd.service

?etcd.service - Etcd Server

Loaded: loaded (/usr/lib/systemd/system/etcd.service; disabled; vendor preset: disabled)

Active: active (running) since Wed 2018-01-03 09:21:36 CST; 1h 41min ago

Main PID: 11426 (etcd)

CGroup: /system.slice/etcd.service

忖11426 /usr/bin/etcd --name=etcd1 --data-dir=/var/lib/etcd/default.etcd --listen-client-urls=http://10.10.200.224:2379,http://127.0.0.1:2379

查看etcd集群状态

[root@k8s-master ~]# etcdctl cluster-health

member 359947fae86629a7 is healthy: got healthy result from http://10.10.200.224:2379

member 4be7ddbd3bb99ca0 is healthy: got healthy result from http://10.10.200.229:2379

member 84951a697d1bf6a0 is healthy: got healthy result from http://10.10.200.230:2379

cluster is healthy

Kubernetes集群配置 master节点配置 1.apiserver配置文件修改，注意KUBE_ADMISSION_CONTROL选项的参数配置

[root@k8s-master ~]# vi /etc/kubernetes/apiserver

###

# kubernetes system config

# The following values are used to configure the kube-apiserver

# The address on the local server to listen to.

#KUBE_API_ADDRESS="--insecure-bind-address=127.0.0.1"

KUBE_API_ADDRESS="--address=0.0.0.0"

# The port on the local server to listen on.

KUBE_API_PORT="--port=8080"

# Port minions listen on

KUBELET_PORT="--kubelet-port=10250"

# Comma separated list of nodes in the etcd cluster

KUBE_ETCD_SERVERS="--etcd-servers=http://10.10.200.224:2379,http://10.10.200.229:2379,http://10.10.200.230:2379"

# Address range to use for services

KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"

# default admission control policies

#KUBE_ADMISSION_CONTROL="--admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota"

KUBE_ADMISSION_CONTROL="--admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,ResourceQuota"

# Add your own!

KUBE_API_ARGS=""

2.启动服务

[root@k8s-master ~]# systemctl start kube-apiserver

[root@k8s-master ~]# systemctl start kube-controller-manager

[root@k8s-master ~]# systemctl start kube-scheduler

[root@k8s-master ~]# systemctl enable kube-apiserver

[root@k8s-master ~]# systemctl enable kube-controller-manager

[root@k8s-master ~]# systemctl enable kube-scheduler

nodes节点配置 1.配置config配置，node1&node2配置相同，以node1为例说明

[root@k8s-node1 ~]# vi /etc/kubernetes/config

###

# kubernetes system config

# The following values are used to configure various aspects of all

# kubernetes services, including

# kube-apiserver.service

# kube-controller-manager.service

# kube-scheduler.service

# kubelet.service

# kube-proxy.service

# logging to stderr means we get it in the systemd journal

KUBE_LOGTOSTDERR="--logtostderr=true"

# journal message level, 0 is debug

KUBE_LOG_LEVEL="--v=0"

# Should this cluster be allowed to run privileged docker containers

KUBE_ALLOW_PRIV="--allow-privileged=false"

# How the controller-manager, scheduler, and proxy find the apiserver

KUBE_MASTER="--master=http://10.10.200.224:8080"

2.配置kubelet

[root@k8s-node1 ~]# vi /etc/kubernetes/kubelet

###

# kubernetes kubelet (minion) config

# The address for the info server to serve on (set to 0.0.0.0 or "" for all interfaces)

KUBELET_ADDRESS="--address=127.0.0.1"

# The port for the info server to serve on

# KUBELET_PORT="--port=10250"

# You may leave this blank to use the actual hostname

KUBELET_HOSTNAME="--hostname-override=10.10.200.229"

# location of the api-server

KUBELET_API_SERVER="--api-servers=http://10.10.200.224:8080"

# pod infrastructure container

KUBELET_POD_INFRA_CONTAINER="--pod-infra-container-image=registry.access.redhat.com/rhel7/pod-infrastructure:latest"

# Add your own!

KUBELET_ARGS=""

网络配置这里使用flannel进行网络配置，已经在2个节点上安装，下面进行配置。在节点上进行配置flannel

[root@k8s-node1 ~]# vi /etc/sysconfig/flanneld

# Flanneld configuration options

# etcd url location. Point this to the server where etcd runs

FLANNEL_ETCD_ENDPOINTS="http://10.10.200.224:2379"

# etcd config key. This is the configuration key that flannel queries

# For address range assignment

FLANNEL_ETCD_PREFIX="/atomic.io/network"

# Any additional options that you want to pass

#FLANNEL_OPTIONS=""

查看集群状态

[root@k8s-master ~]# kubectl get nodes

NAME STATUS AGE

10.10.200.229 Ready 1h

10.10.200.230 Ready 1h

[root@k8s-master ~]# etcdctl member list

359947fae86629a7: name=etcd1 peerURLs=http://10.10.200.224:2380 clientURLs=http://10.10.200.224:2379 isLeader=true

4be7ddbd3bb99ca0: name=etcd2 peerURLs=http://10.10.200.229:2380 clientURLs=http://10.10.200.229:2379 isLeader=false

84951a697d1bf6a0: name=etcd3 peerURLs=http://10.10.200.230:2380 clientURLs=http://10.10.200.230:2379 isLeader=false

[root@k8s-master ~]# etcdctl cluster-health

member 359947fae86629a7 is healthy: got healthy result from http://10.10.200.224:2379

member 4be7ddbd3bb99ca0 is healthy: got healthy result from http://10.10.200.229:2379

member 84951a697d1bf6a0 is healthy: got healthy result from http://10.10.200.230:2379

cluster is healthy

测试使用在测试使用前，现在2个节点上手动下载pod images，以及测试使用的nginx images

[root@k8s-node1 ~]# docker pull registry.access.redhat.com/rhel7/pod-infrastructure:latest

[root@k8s-node1 ~]# docker pull nginx

运行nginx

1 2	[root@k8s-master ~]# kubectl run my-nginx --image=nginx --replicas=2 --port=80 deployment "my-nginx" created

查看pods

[root@k8s-master ~]# kubectl get pods

NAME READY STATUS RESTARTS AGE

my-nginx-379829228-55s8n 1/1 Running 0 39s

my-nginx-379829228-th5t1 1/1 Running 0 39s

可以在node节点上查看到对应的containers […]

龙生 08 Nov 2018

View Details

K8s基本概念入门

序言没等到风来，绵绵小雨，所以写个随笔，聊聊k8s的基本概念。 k8s是一个编排容器的工具，其实也是管理应用的全生命周期的一个工具，从创建应用，应用的部署，应用提供服务，扩容缩容应用，应用更新，都非常的方便，而且可以做到故障自愈，例如一个服务器挂了，可以自动将这个服务器上的服务调度到另外一个主机上进行运行，无需进行人工干涉。那么，问题来了，要运维何用？ k8s可以更快的更新新版本，打包应用，更新的时候可以做到不用中断服务，服务器故障不用停机，从开发环境到测试环境到生产环境的迁移极其方便，一个配置文件搞定，一次生成image，到处运行。。。 k8s的全生命周期管理在k8s进行管理应用的时候，基本步骤是：创建集群，部署应用，发布应用，扩展应用，更新应用。 1、创建集群：为什么要使用集群？有一句古话叫做三个臭皮匠，赛过诸葛亮，这就是创建集群的原因。。。使用集群，create cluster是为了掩盖底层的无能，在各种环境中，底层的硬件各不相同，有的是各种低廉的服务器，有的各种云环境，有的是各种vm，有的各种host machine，要想屏蔽底层的细节，增强可靠性和稳定性，从而需要创建集群。创建集群的好处就是，统一对外提供接口，无须进行各种复杂的调用；提供更好的可靠性，服务器宕机那么频繁，物理磁盘那么容易损坏，无须担心，集群统一进行调配；提供更好的性能，组合集群中各个机器的计算存储网络资源，提供更好的TPS和PS；提供横向扩容的能力，在进行横向扩容的时候，性能基本上能呈线性增长。集群看起来很牛，那么创建起来很复杂么？并不会，在k8s只要使用两条指令就可以创建一个集群，一个是kubectl init进行初始化，创建一个master节点，第二条指令就是kubectl join xxx创建一个node节点，加入这个集群。在这边可以看到k8s在物理上进行划分的时候，划分了两种类型的主机，一个master节点，主要用来调度，控制集群的资源等功能；而node节点，主要是用来运行容器的节点，也就是运行服务的节点。其实集群都差不多，master用来控制，用来存储各种元数据，node节点是一个工作节点，真正来干活的；node节点定时与master进行通信，通过kubelet进程来汇报信息。创建了集群，我要怎么看信息？如下： 2、部署应用使用集群的主要目标是啥？用来提供服务，让开发开发的应用程序能在集群上运行，从而需要让开发能运行一个应用来进行测试。一条指令就能运行一个服务，有了image之后就是这么简单。所以，在开发完成程序之后，需要将程序打包成image，然后放到registry中，然后就能够运行应用了。在部署完成应用之后，就可以看到应用的名称，期望状态是运行一个pod，当前有一个pod，活动的也是一个，还有启动的时间，那么什么是pod呢？在k8s里面，集群调度的最小单元就是一个pod，一个pod可以是一个容器，也可以是多个容器，例如你运行一个程序，其中使用了nginx，使用mysql了，使用了jetty，那么可以将这三个使用在同一个pod中，对他们提供统一的调配能力，一个pod只能运行在一个主机上，而一个主机上可以有多个pod。那么有人会问，为什么要使用pod，为什么不能直接使用容器呢？使用pod，相当与一个逻辑主机，还记得创建一个vm，在vm上运行几个进程么，其实道理是一样的，pod的存在主要是让几个紧密连接的几个容器之间共享资源，例如ip地址，共享存储等信息。如果直接调度容器的话，那么几个容器可能运行在不同的主机上，这样就增加了系统的复杂性。 3、发布应用发布应用主要就是对外提供服务，可能会有人提出疑问，我都运行了服务，为什么还不能提供服务，这是因为在集群当中，创建的ip地址等资源，只有在同一个集群中才能访问，每个pod也有独一的ip地址，当有多个pod提供相同的服务的时候，就需要有负载均衡的能力，从而这里就涉及到一个概念就是service，专门用来提供服务的。服务主要是用来提供外界访问的接口，服务可以关联一组pod，这些pod的ip地址各不相同，而service相当于一个复杂均衡的vip，用来指向各个pod，当pod的ip地址发生改变之后，也能做到自动进行负载均衡，在关联的时候，service和pod之间主要通过label来关联，也就是标签（-l表示为label）。从而外界就可以访问此应用了，如下： 4、扩容缩容在业务上线之后，碰到了双十一怎么办？扩容。。。万剑归宗，只要有一个pod，那么就可以产生无数个pod。。。。过了双十一怎么办，缩容。。。横向扩展的能力。。每次扩容缩容的时候，这种会不会觉得很方便，一句话的事儿。。不用创建vm，不用去部署中间件，不用去各种修改配置，这就是自动化。。。 5、更新有新版本了，我要发布。。。那么。。。滚动更新。。。根据新的image创建一个pod，分配各种资源，然后自动负载均衡，删除老的pod，然后继续更新。。。。不会中断服务。。。更新错了怎么办，不怂，不会影响生产业务，回滚就好了。。。几秒钟的事儿。。。后话 k8s的基本入门，其实算是一种用户视角，只是用来演示如何使用k8s，怎么提高了生产力而已。在给客户演示的时候，为啥要选择k8s？主要就是如何提高了发布的效率，更新版本的效率，更方便更快捷的上线新版本。但是在运维关注的视角下，这些远远不够。。。master？存储了哪些元数据，存储在etcd中？如何来进行监控？在很多很多系统情况下，怎么来部署k8s，是一个项目一个k8s还是一个k8s多个项目？等等一系列的问题。。。 from:https://blog.csdn.net/TM6zNf87MDG7Bo/article/details/79621510

龙生 08 Nov 2018

View Details

为 .NET Core 应用程序生成 Docker 映像

本教程重点介绍了如何在 Docker 上使用 .NET Core。首先，我们探讨 Microsoft 维护和提供的各种不同的 Docker 映像，及其使用情况。然后讲解了如何生成和 Docker 化 ASP.NET Core 应用。在本教程中可学习：了解 Microsoft.NET 核心 Docker 映像获取用于 dockerize 的 ASP.NET Core 示例应用程序在本地运行 ASP.NET 示例应用使用 Docker for Linux 容器生成和运行示例使用 Docker for Windows 容器生成和运行示例 Docker 映像优化为开发人员生成 Docker 映像时，侧重于以下三种主要方案：用于开发 .NET Core 应用的映像用于生成 .NET Core 应用的映像用于运行 .NET Core 应用的映像为什么是三个映像？因为在开发、生成和运行容器化应用程序时，具有不同的优先级。开发：优先级注重循环访问更改的速度以及调试更改的能力。与更改代码并且快速查看相比，映像的大小是否不是那么重要？生成：此映像包含编译应用所需的所有内容，其中包括编译器和任何其他用于优化二进制文件的依赖项。可使用生成映像创建置于生产映像中的资产。生成映像用于持续集成或用于生成环境中。此方法允许生成代理在生成映像实例中编译和生成应用程序（包括所有必需的依赖项）。生成代理只需要了解如何运行此 Docker 映像即可。生产：部署和启动映像的速度可以有多快？此映像很小，因此从 Docker 注册表到 Docker 主机的网络性能得到了优化。已准备运行内容，以此实现从 Docker 运行到处理结果的最快时间。 Docker 模型中不需要动态代码编译。放置在此映像中的内容将限制为运行应用程序所需的二进制文件和内容。例如，dotnet publish 输出包含：已编译的二进制文件 .js 和 .css 文件在生产映像中包括 dotnet publish 命令输出的原因是使生产映像保持最小大小。某些 .NET Core 映像共享不同标记之间的层，因此下载最新标记是一个相对轻量的过程。如果计算机上已有较早版本，此体系结构会降低所需的磁盘空间。当多个应用程序在同一计算机上使用公共映像时，在公共映像之间共享内存。映像必须相同才可共享。 Docker 映像变体为了实现上述目标，我们在 microsoft/dotnet 下提供了映像变体。 microsoft/dotnet:<version>-sdk(microsoft/dotnet:2.1-sdk) 此映像包含带有 […]

龙生 22 Oct 2018

View Details

Docker 容器、映像和注册表

使用 Docker 时，开发人员会创建一个应用或服务，并将它及其依赖项打包到一个容器映像中。映像是应用或服务及其配置和依赖项的静态表示形式。若要运行应用或服务，应用的映像会实例化，以创建一个在 Docker 主机上运行的容器。最初，会在开发环境或 PC 中测试容器。开发人员应将映像存储在注册表中，该注册表可充当映射库并在部署到生产业务流程协调程序时使用。 Docker 通过 Docker 中心维护公共注册表；其他供应商为不同映像集合提供注册表，包括 Azure 容器注册表。或者，企业可以拥有一个本地专用注册表，用于其 Docker 映像。图 2-4 显示了 Docker 中的映像和注册表与其他组件相关联的方式。还显示了供应商的多个注册表产品/服务。图 2-4。 Docker 术语和概念的分类将映射存储到注册表中可存储静态和不可变的应用程序，包括其在框架级别的所有依赖项。然后，这些映像可部署到多种环境中，并进行版本控制，从而提供一致的部署单元。无论是托管在本地还是托管在云中，在下列情况下都建议使用专用映像注册表：由于保密性，不能公开分享映像。在映像和所选部署环境之间，希望网络延迟保持最低。例如，如果生产环境是 Azure 云，为实现最低的网络延迟，可将映像存储在 Azure 容器注册表中。同样，如果生产环境是在本地，便需要使本地 Docker 信任的注册表在相同的本地网络中可用。 from:https://docs.microsoft.com/zh-cn/dotnet/standard/microservices-architecture/container-docker-introduction/docker-containers-images-registries

龙生 22 Oct 2018

View Details

Docker 术语

本节列出了在深入了解 Docker 之前应熟悉的术语和定义。有关进一步的定义，请参阅 Docker 提供的详细术语表。容器映像：包含创建容器所需的所有依赖项和信息的包。映像包括所有依赖项（例如框架），以及容器运行时使用的部署和执行配置。通常情况下，映像派生自多个基础映像，这些基础映像是堆叠在一起形成容器文件系统的层。创建后，映像不可变。 Dockerfile：包含有关如何生成 Docker 映像的说明的文本文件。与批处理脚本相似，首先第一行将介绍基础映像，然后是关于安装所需程序、复制文件等操作的说明，直至获取所需的工作环境。生成：基于其 Dockerfile 提供的信息和上下文生成容器映像的操作，以及生成映像的文件夹中的其他文件。可以使用 Docker 的“docker 生成”命令生成映像。容器：Docker 映像的实例。容器表示单个应用程序、进程或服务的执行。它由 Docker 映像的内容、执行环境和一组标准指令组成。在缩放服务时，可以从相同的映像创建多个容器实例。或者，批处理作业可以从同一个映像创建多个容器，向每个实例传递不同的参数。卷：提供一个容器可以使用的可写文件系统。由于映像只可读取，而多数程序需要写入到文件系统，因此卷在容器映像顶部添加了一个可写层，这样程序就可以访问可写文件系统。程序并不知道它正在访问的是分层文件系统，此文件系统就是往常的文件系统。卷位于主机系统中，由 Docker 管理。标记：可以应用于映像的标记或标签，以便可以识别同一映像的不同映像或版本（具体取决于版本号或目标环境）。多阶段生成：Docker 17.05 或更高版本的一个功能，可帮助减小最终映像的大小。概括来说，借助多阶段生成，可以使用一个包含 SDK 的大型基础映像（以此为例）编译和发布应用程序，然后使用发布文件夹和一个小型仅运行时基础映像生成一个更小的最终映像存储库 (repo)：相关的 Docker 映像集合，带有指示映像版本的标记。某些存储库包含特定映像的多个变量，例如包含 SDK（较重）的映像，包含唯一运行时（较轻）的映像，等等。这些变量可以使用标记进行标记。单个存储库中可包含平台变量，如 Linux 映像和 Windows 映像。注册表：提供存储库访问权限的服务。大多数公共映像的默认注册表是 Docker 中心（归作为组织的 Docker 所有）。注册表通常包含来自多个团队的存储库。公司通常使用私有注册表来存储和管理其创建的映像。另一个示例是 Azure 容器注册表。多体系结构映像：就多体系结构而言，它是一种根据运行 Docker 的平台简化相应映像选择的功能，例如当 Dockerfile 从注册表请求基础映像 FROM microsoft/dotnet:2.1-sdk 时，实际上它会获得 2.1-sdk-nanoserver-1709、2.1-sdk-nanoserver-1803 或 2.1-sdk-alpine，具体取决于操作系统和运行 Docker 的版本。 Docker Hub：上传并使用映像的公共注册表。 Docker 中心提供 Docker 映像托管、公共或私有注册表，生成触发器和 Web 挂钩，以及与 GitHub 和 Bitbucket 集成。 Azure 容器注册表：用于在 Azure 中使用 Docker 映像及其组件的公共资源。这提供了接近 Azure 中部署的注册表，授予控制访问权限，使其可以使用 Azure Active Directory 组和权限。 Docker 受信任注册表 (DTR)：Docker 注册表服务（来自 Docker），可以安装在本地，因此它存在于组织的数据中心和网络中。这对于应该在企业内部管理的私有映像来说很方便。 Docker 受信任注册表是 Docker 数据中心产品的一部分。有关详细信息，请参阅 Docker 受信任注册表 […]

龙生 22 Oct 2018

View Details

« Previous 1 … 5 6 7 8 Next »