使用Helm将ASP.NET Core应用程序部署到Kubernetes容器集群
在《容器化单页面应用中RESTful API的访问》以及《容器化单页面应用中Nginx反向代理与Kubernetes部署》两篇文章中,我介绍了一套容器化ASP.NET Core应用程序的方案,并对于Nginx反向代理的使用进行了介绍。在《使用Rancher在Microsoft Azure上搭建Kubernetes集群》一文中,我介绍了一种基于Rancher搭建Kubernetes容器集群的方案,大家会发现,使用Rancher来部署和管理Kubernetes容器集群非常方便。今天,我将结合这三篇文章的内容,将案例程序name-list封装成Helm Chart,然后部署到Kubernetes容器集群中。
要使用Helm来部署我们的案例程序,首先就是要安装Helm。Helm安装分两个步骤,先安装客户端,然后安装它的服务端部件Tiller。Tiller是运行在Kubernetes集群中的,有关Helm和Tiller的基础知识和基本概念,请参考官方文档,本文不会做过多介绍。
安装Helm客户端非常简单,官网上提供了多种安装方式。最简单的方式就是直接到Helm的Github repo,找到所需的版本下载后解压,然后将路径添加到系统的PATH环境变量,即可使用Helm客户端。之后,我们可以使用下面的命令验证客户端是否安装成功:
1 2 3 |
|
注意:在使用该命令之前,请先确保已经成功部署了Kubernetes,并且~/.kube/config文件中设置了正确的context。有关Kubernetes的部署,请参考《使用Rancher在Microsoft Azure上搭建Kubernetes集群》一文。
上面的命令用于检查Helm的版本,包括客户端版本和服务端Tiller的版本。由于我们还没有安装服务端,因此,提示“Error: could not find tiller”的错误信息。
使用下面的命令创建一个名为tiller的Service Account,然后将其赋予cluster-admin的角色,最后使用该Service Account安装Tiller:
|
待安装成功后,再次运行helm version,可以看到类似如下的信息,表示Helm以及Tiller安装成功。
|
Helm中有几个比较关键的概念,Helm Chart指的是一套应用程序部署的定义,比如一次Helm部署包含哪些Kubernetes的deployment以及service等等;Helm Release则表示一次应用程序的部署。在之前介绍name-list案例的文章中,我使用了docker-compose来组织各个所需的服务及其之间的依赖关系,并使用docker-compose命令行工具来实现整个应用程序的编译、容器化以及容器运行等任务。现在,我们仍然依赖这个docker-compose.yml文件来创建Helm Chart。
首先,到Kubernetes Kompose官方Github repo下载Kompose命令行工具,然后,在docker-compose.yml文件所在的目录中,运行:
1 |
|
此时,会在docker-compose.yml文件所在目录中,出现一个helm的子目录,然后,在该目录中,会包含Helm Chart相关的目录和文件。以name-list案例为例:
helm:包含了两个文件和一个子目录:templates
Chart.yaml:Helm Chart的定义文件,里面可以指定Helm Chart的名称、描述等
README.md:说明文件,可以无视
templates目录:该目录下包含了应用程序部署的deployment、service以及ingress的描述文件,也是Helm Chart的主要部分
此外,helm目录下还可以有values.yaml文件,用来定义一些用户可以修改的变量,例如,可以在values.yaml中,使用“serviceTcpPort: 8080”来指定服务的端口号为8080,然后,在template中使用{{ .Values.serviceTcpPort }}来表示需要从values.yaml中读取服务的端口号。在name-list案例中,没有用到values.yaml。
默认情况下,Kompose会将基本的template文件都创建好,然后,还需要根据应用程序的情况进行一些手工调整,比如,将Helm Release的名称作为每个生成的deployment和service的名称前缀就是一个不错的习惯,这就需要手工地对生成的template文件进行调整。比如,在name-list案例中,前端应用的service定义如下:
|
在高亮的几行,使用{{ .Release.Name }}来表示当前Helm Release的名称。因此,对于name-list的前端应用而言,在部署到Kubernetes之后,该前端服务的名称就是{{ .Release.Name }}-namelist-client,虽然在Kubernetes集群中,可以通过这个前缀来区分不同的Helm Release,但对于Nginx来说,它将无法找到这个前端服务,因为目前我们的Nginx配置如下:
|
可以看到,在Nginx配置中,前端服务的主机地址被写死成namelist-client了,而在我们的Helm Release中,应该是{{ .Release.Name }}-namelist-client。下面我们来解决这个问题。
解决Nginx中主机名称的问题,可以使用dockerize工具,它的官方Github repo是:https://github.com/jwilder/dockerize。dockerize可以在容器启动的时候,实现模板替换,将容器环境变量的值替换到指定模板文件中。比如,对于Nginx的配置而言,我们可以首先定义一个nginx.conf.tmpl的文件,在其中使用一些模板变量,然后使用dockerize,使其在容器启动时,使用环境变量来替换这些模板变量,于是,容器运行时所使用的nginx.conf文件就是dockerize最终生成的文件。
仍然以name-list为例,首先,定义一个nginx.conf.tmpl文件,内容如下:
|
其中{{ .Env.RELEASE_NAME }}表示使用RELEASE_NAME环境变量来替换当前位置的值。然后,修改Nginx所在容器的Dockerfile,内容如下:
|
这个Dockerfile的关键部分就是最后一行,它会调用dockerize命令,将之前编入容器的/etc/nginx/sites-available/default.tmpl文件替换并输出为/etc/nginx/sites-available/default文件。
再看看Nginx的deployment.yaml中,是如何设置这个RELEASE_NAME环境变量的:
|
由此可见,Helm Release的名称,也就是{{ .Release.Name }}的值,被作为环境变量RELEASE_NAME的值,注入到daxnet/namelist-nginx容器中。
在Chart.yaml所在目录,运行下面的命令,将name-list部署到Kubernetes集群,我们将这次部署命名为myapp:
1 |
|
运行结果如下:
使用kubectl get pods命令查看所有pod是否正常运行:
使用kubectl exec查看Nginx是否正确配置:
使用helm list命令,查看我们的Helm Releases:
在Microsoft Azure中,找到由Rancher创建的Kubernetes节点虚机,确保80端口已在安全组中打开,然后访问该虚拟机的IP地址,可以看到,我们的name-list案例已经成功运行在Kubernetes集群中:
本文主要介绍了使用Helm将ASP.NET Core应用程序部署到Kubernetes容器集群的方法,并对其中遇到的问题进行了概括性描述。事实上,本文所使用的name-list案例是一套集前端、后端以及Nginx于一体的完整案例,代码完全免费开源,地址是:https://github.com/daxnet/name-list。有需要的读者欢迎查阅。
原文链接:https://sunnycoding.cn/2019/10/02/deploying-aspnetcore-apps-to-kubernetes-with-helm/
.NET社区新闻,深度好文,欢迎访问公众号文章汇总 http://www.csharpkit.com
使用Helm将ASP.NET Core应用程序部署到Kubernetes容器集群相关推荐
- asp网上书店的代码_使用Helm将ASP.NET Core应用程序部署到Kubernetes容器集群
在<容器化单页面应用中RESTful API的访问>以及<容器化单页面应用中Nginx反向代理与Kubernetes部署>两篇文章中,我介绍了一套容器化ASP.NET Core ...
- linux运行core控制台程序,VisualStudioCode创建的asp.net core控制台程序部署到linux
1.asp.net core控制台程序 static void Main(string[] args) {int times=10;while(times>=0) { Console.Write ...
- linux .net 控制台应用程序,VisualStudioCode创建的asp.net core控制台程序部署到linux
1.asp.net core控制台程序 static void Main(string[] args) {int times=10;while(times>=0) { Console.Write ...
- 运行Vue在ASP.NET Core应用程序并部署在IIS上
前言 从.NET Core 1.0开始我们就将其应用到项目中,但是呢我对ASP.NET Core一些原理也还未开始研究,仅限于会用,不过园子中已有大量文章存在,借着有点空余时间,我们来讲讲如何利用AS ...
- 如何在Ubuntu 18.04上使用Nginx与MySQL服务器一起部署ASP.NET Core应用程序
The author selected the Open Source Initiative to receive a donation as part of the Write for DOnati ...
- 在ASP.NET Core应用程序中使用分布式缓存
本文要点 ASP.NET Core内置了分布式缓存接口. 分布式缓存的主要好处有性能.数据共享和稳定性. Couchbase服务器是一个内存优先的数据库,非常适合作为分布式缓存. NuGet程序包使得 ...
- 5种设置ASP.NET Core应用程序URL的方法
默认情况下,ASP.NET Core应用程序监听以下URL: •http://localhost:5000•https://localhost:5001 在这篇文章中,我展示了5种不同的方式来更改您的 ...
- 将终结点图添加到你的ASP.NET Core应用程序中
在本文中,我将展示如何使用DfaGraphWriter服务在ASP.NET Core 3.0应用程序中可视化你的终结点路由.上面文章我向您演示了如何生成一个有向图(如我上篇文章[译]使用DOT语言和G ...
- 使用Azure Application Insignhts监控ASP.NET Core应用程序
Application Insignhts是微软开发的一套监控程序.他可以对线上的应用程序进行全方位的监控,比如监控每秒的请求数,失败的请求,追踪异常,对每个请求进行监控,从http的耗时,到SQL查 ...
最新文章
- ssh 到另一台机器执行命令
- Java反射机制Reflection
- Python基础实践-密码管理系统实例
- Windows2003 安装AD失败,未能为域创建GPO,出现了扩展错误 的解决方法
- linux输入子系统
- RAR 5.50 控制台使用记录
- IE和火狐CSS透明层兼容写法
- vue el-tree 默认选中_Vue UI:Vue开发者必不可少的工具
- Oracle视图传递参数
- 在Visual Studio 2010中创建多项目(解决方案)模板【一】
- vc6.0项目到vc2013移植记录
- 苹果画画软件_入手新iPad,这几款绘画软件必不可少!
- 判断360浏览器极速和兼容模式
- Linux串口调试工具,可视化界面
- Docker 镜像加速器配置
- 传销三级的认定标准_应为传销案件中“劳务性工作人员”争取“不起诉”—传销犯罪辩护与研究(四十五)...
- Ubuntu 16.04 安装opencv3及其扩展模块
- ubuntu14.04安装skype4.3
- 基于html的旅游网站的设计与实现
- Springboot启动后频繁打印错误日志 /null/swagger-ui.html解决方案
热门文章
- Sys.WebForms.PageRequestManagerTimeoutException:服务器请求超时
- 不断电系统的容量如何计算?
- Unity3D笔记十 游戏元素
- DOCKER存储驱动之DEVICE MAPPER简介
- App Store 排名获取。
- 利用Xshell实现非对称秘钥对安全登陆linux服务器(Centos、Ubuntu)
- javascript高程3 学习笔记(三)
- Eclipse C++的配置问题launch failed binary not found
- ubuntu下mysql-python模块的安装
- N 年沉淀,腾讯这套系统终于开源!