非自己的网站如何做二次跳转,东莞市做网络维护的公司,淘宝网页制作代码,在线做汉字头像的网站在《容器化单页面应用中RESTful API的访问》以及《容器化单页面应用中Nginx反向代理与Kubernetes部署》两篇文章中#xff0c;我介绍了一套容器化ASP.NET Core应用程序的方案#xff0c;并对于Nginx反向代理的使用进行了介绍。在《使用Rancher在Microsoft Azure上搭建Kuberne… 在《容器化单页面应用中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客户端。之后我们可以使用下面的命令验证客户端是否安装成功123$ helm versionClient: version.Version{SemVer:v2.14.3, GitCommit:0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085, GitTreeState:clean}Error: could not find tiller注意在使用该命令之前请先确保已经成功部署了Kubernetes并且~/.kube/config文件中设置了正确的context。有关Kubernetes的部署请参考《使用Rancher在Microsoft Azure上搭建Kubernetes集群》一文。上面的命令用于检查Helm的版本包括客户端版本和服务端Tiller的版本。由于我们还没有安装服务端因此提示“Error: could not find tiller”的错误信息。使用下面的命令创建一个名为tiller的Service Account然后将其赋予cluster-admin的角色最后使用该Service Account安装Tiller$ kubectl -n kube-system create serviceaccount tiller$ kubectl create clusterrolebinding tiller \ --clusterrolecluster-admin \ --serviceaccountkube-system:tiller$ helm init --service-account tiller待安装成功后再次运行helm version可以看到类似如下的信息表示Helm以及Tiller安装成功。$ helm versionClient: version.Version{SemVer:v2.14.3, GitCommit:0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085, GitTreeState:clean}Server: version.Version{SemVer:v2.14.3, GitCommit:0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085, GitTreeState:clean}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$ kompose convert -c -o helm此时会在docker-compose.yml文件所在目录中出现一个helm的子目录然后在该目录中会包含Helm Chart相关的目录和文件。以name-list案例为例helm包含了两个文件和一个子目录templatesChart.yamlHelm 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定义如下apiVersion: v1kind: Servicemetadata: annotations: kompose.cmd: kompose convert -o k8s.deployment.yaml kompose.version: 1.18.0 (06a2e56) creationTimestamp: null labels: io.kompose.service: {{ .Release.Name }}-namelist-client name: {{ .Release.Name }}-namelist-clientspec: ports: - name: 80 port: 80 targetPort: 80 selector: io.kompose.service: {{ .Release.Name }}-namelist-clientstatus: loadBalancer: {}在高亮的几行使用{{ .Release.Name }}来表示当前Helm Release的名称。因此对于name-list的前端应用而言在部署到Kubernetes之后该前端服务的名称就是{{ .Release.Name }}-namelist-client虽然在Kubernetes集群中可以通过这个前缀来区分不同的Helm Release但对于Nginx来说它将无法找到这个前端服务因为目前我们的Nginx配置如下events { worker_connections 1024;}http { server { listen 80; server_name localhost; resolver 127.0.0.11 ipv6off; include /etc/nginx/mime.types; location / { } location ~ ^/name-service/(.*)$ { rewrite ^ $request_uri; rewrite ^/name-service/(.*)$ $1 break; return 400; } } upstream namelistsvc { server namelist-service:5000; } upstream namelistcli { server namelist-client:80; }}可以看到在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文件内容如下server { listen 80; server_name localhost; include /etc/nginx/mime.types; location / { } location ~ ^/name-service/(.*)$ { rewrite ^ $request_uri; rewrite ^/name-service/(.*)$ $1 break; return 400; }}upstream namelistsvc { server {{ .Env.RELEASE_NAME }}-namelist-service:5000;}upstream namelistcli { server {{ .Env.RELEASE_NAME }}-namelist-client:80;}其中{{ .Env.RELEASE_NAME }}表示使用RELEASE_NAME环境变量来替换当前位置的值。然后修改Nginx所在容器的Dockerfile内容如下FROM ubuntu:14.04ENV DOCKERIZE_VERSIONv0.6.1# Install Nginx.# RUN apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C300EE8CRUN apt-get updateRUN apt-get install -y wget nginxRUN echo daemon off; /etc/nginx/nginx.confRUN tar -C /usr/local/bin -xvzf dockerize-linux-amd64-$DOCKERIZE_VERSION.tar.gzADD nginx.conf.tmpl /etc/nginx/sites-available/default.tmplEXPOSE 80CMD dockerize -template /etc/nginx/sites-available/default.tmpl:/etc/nginx/sites-available/default -stdout /var/log/nginx/access.log -stderr /var/log/nginx/error.log nginx这个Dockerfile的关键部分就是最后一行它会调用dockerize命令将之前编入容器的/etc/nginx/sites-available/default.tmpl文件替换并输出为/etc/nginx/sites-available/default文件。再看看Nginx的deployment.yaml中是如何设置这个RELEASE_NAME环境变量的apiVersion: extensions/v1beta1kind: Deploymentmetadata: annotations: kompose.cmd: kompose convert -c -o helm kompose.version: 1.18.0 (06a2e56) creationTimestamp: null labels: io.kompose.service: {{ .Release.Name }}-namelist-nginx name: {{ .Release.Name }}-namelist-nginxspec: replicas: 1 strategy: {} template: metadata: creationTimestamp: null labels: io.kompose.service: {{ .Release.Name }}-namelist-nginx spec: containers: - image: daxnet/namelist-nginx name: namelist-nginx env: - name: RELEASE_NAME value: {{ .Release.Name | quote }} ports: - containerPort: 80 resources: {} restartPolicy: Alwaysstatus: {}由此可见Helm Release的名称也就是{{ .Release.Name }}的值被作为环境变量RELEASE_NAME的值注入到daxnet/namelist-nginx容器中。在Chart.yaml所在目录运行下面的命令将name-list部署到Kubernetes集群我们将这次部署命名为myapp1$ helm upgrade --install myapp .运行结果如下使用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
