NGINX大全 第十一章 容器/微服务

第十一章 容器/微服务

11.0 介绍

容器在应用程序层提供了一层抽象，将包和依赖的安装从部署转移到了构建过程。这很重要，因为工程师现在提供的代码单元无论环境如何都以统一的方式运行和部署。将容器作为可运行单元进行升级可降低环境之间依赖性和配置混乱的风险。鉴于此，对于组织机构很有必要在集装箱平台上部署应用程序。在容器平台上运行应用程序时，通常会尽可能多使堆栈容器化，包括代理或负载均衡器。NGINX和NGINX Plus易于容器化运输。它们还包括许多使容器化的应用流畅运输的特性。本章重点介绍如何构建NGINX和NGINX Plus容器镜像，使容器化环境更容易工作的特性，以及在Kubernetes和OpenShift上部署镜像。

11.1 DNS SRV记录

只能在NGINX Plus中使用。下略。

11.2 使用官方NGINX镜像

问题

您需要使用Docker Hub中的NGINX镜像快速启动并运行。

解决方案

使用Docker Hub中的NGINX镜像。此镜像包含一个默认配置。您得要么挂载一个本地配置目录，要么创建一个Dockerfile，并在配置中ADD到镜像构建以更改配置。在这里，我们挂载一个卷，其中NGINX的默认配置提供静态内容，使用一个简单的命令来演示其功能：

$ docker run --name my-nginx -p 80:80 \
-v /path/to/content:/usr/share/nginx/html:ro -d nginx

如果在本地找不到，那么docker命令会从Docker Hub中提取nginx：latest镜像。然后该命令将此NGINX镜像作为Docker容器运行，将localhost：80映射到NGINX容器的端口80。它还将本地目录/path/to/content/作为容器卷挂载在/usr/share/nginx/html/，并设为只读。默认的NGINX配置将此目录作为静态内容提供。指定从本地计算机到容器的映射时，首先是本地计算机端口或目录，然后是容器端口或目录。

讨论

NGINX通过Docker Hub提供了官方Docker镜像。这个官方的Docker镜像使您可以轻松地在Docker中快速启动并运行您最喜欢的应用交付平台NGINX。在本节中，我们能够通过一个简单的命令在一个容器中启动和运行NGINX！ 我们在这个例子中使用的官方NGINX Docker镜像主线是基于Debian Jessie Docker镜像构建的。但是，您可以选择基于Alpine Linux构建的官方镜像。这些官方镜像的Dockerfile和源代码可在GitHub上找到。您可以通过构建自己的Dockerfile并在FROM命令中指定官方镜像来扩展官方映像。

11.3 创建NGINX Dockerfile

问题

为创建Docker镜像，您需要创建一个NGINX Dockerfile。

解决方案

FROM从您选择的发行版的Docker镜像开始。使用RUN命令安装NGINX。使用ADD命令添加您的NGINX配置文件。使用EXPOSE命令指示Docker公开给定的端口，或者在将镜像作为容器运行时手动执行此操作。当镜像作为容器实例化时，使用CMD启动NGINX。您需要在前台运行NGINX。为此，您需要使用-g "daemon off;"启动NGINX或在配置中添加daemon off;。本示例将在将后面的与主上下文的配置文件中的daemon off;一起使用。您还需要更改NGINX配置，以将访问日志记录到/dev/stdout，并将错误日志记录到/dev/stderr； 这样做会将您的日志放入Docker守护进程，这将使您可以更轻松地使用它们，基于您选择的与Docker一起使用的日志驱动程序：

Dockerfile:

FROM centos:7

# Install epel repo to get nginx and install nginx
RUN yum -y install epel-release && \
    yum -y install nginx

# add local configuration files into the image
ADD /nginx-conf /etc/nginx

EXPOSE 80 443

CMD ["nginx"]

目录结构如下所示：

. ├── Dockerfile └── nginx-conf ├── conf.d │ └── default.conf ├── fastcgi.conf ├── fastcgi_params ├── koi-utf ├── koi-win ├── mime.types ├── nginx.conf ├── scgi_params ├── uwsgi_params └── win-utf

我选择将整个NGINX配置托管在此Docker目录中，以便于访问所有配置，而在Dockerfile中仅保留一行以添加我的所有NGINX配置。

讨论

当需要完全控制已安装的软件包和更新时，您会发现创建自己的Dockerfile很有用。保留自己的镜像仓库是很常见的，这样您就可以知道基础镜像是可靠的，并且在生产中运行前已被团队测试。

11.4 构建NGINX Plus镜像

只能在NGINX Plus中使用。下略。

11.5 在NGINX中使用环境变量

问题

您需要在NGINX配置中使用环境变量，以便将相同的容器镜像用于不同的环境。

解决方案

使用ngx_http_perl_module从您的环境中设置变量到NGINX中：

daemon off;
env APP_DNS;
include /usr/share/nginx/modules/*.conf;
...
http {
    perl_set $upstream_app 'sub { return $ENV{"APP_DNS"}; }';
    server {
        ...
        location / {
            proxy_pass https://$upstream_app;
        }
    }
}

要使用perl_set，必须安装ngx_http_perl_module。 你可以动态地加载该模块或者从源码构建静态加载。默认情况下，NGINX会从其环境中擦除环境变量； 您需要使用env指令声明任何不想删除的变量。perl_set指令采用两个参数：您要设置的变量名称和呈现结果的perl字符串。

以下是一个动态加载ngx_http_perl_module的Dockerfile，它通过包管理实用程序安装此模块。从CentOS的包实用程序安装模块时，它们被置于/usr/lib64/nginx/modules/目录中，而动态加载这些模块的配置文件被置于/usr/share/nginx/modules/目录中。这就是为什么在前面的配置片段中，我们在该路径中include所有配置文件：

FROM centos:7

# Install epel repo to get nginx and install nginx
RUN yum -y install epel-release && \
    yum -y install nginx nginx-mod-http-perl

# add local configuration files into the image
ADD /nginx-conf /etc/nginx

EXPOSE 80 443

CMD ["nginx"]

讨论

使用Docker的典型做法是利用环境变量来更改容器的运行方式。您可以在NGINX配置中使用环境变量，以便NGINX Dockerfile可以在多个不同的环境中使用。

11.6 Kubernetes Ingress控制器

问题

您正在Kubernetes上部署应用程序，并且需要一个入口控制器。

解决方案

确保您有权访问入口控制器镜像。对于NGINX，您可以使用Docker-Hub中的nginx/nginx-ingress镜像。对于NGINX Plus，您将需要构建自己的镜像并将其托管在私有Docker注册表中。您可以在NGINX Inc.的GitHub上找到有关构建和推送自己的NGINX Plus Kubernetes Ingress Controller的说明。

访问GitHub上kubernetes-ingress仓库中的Kubernetes Ingress Controller Deployments文件夹。下面的命令将在这个仓库的本地副本的该目录中运行。

为入口控制器创建名称空间和服务帐户； 两者都被命名为nginx-ingress：

$ kubectl apply -f common/ns-and-sa.yaml

为入口控制器创建带有TLS证书和密钥的密钥：

$ kubectl apply -f common/default-server-secret.yaml

这个证书和密钥是由NGINX Inc.自签名并创建的，用于测试和示例目的。 由于此密钥是公开可用的，因此建议您使用自己的密钥。

可选的，您可以创建用于自定义NGINX配置的配置映射表（提供的配置映射表是空的；但是，您可以在此处阅读有关自定义和注释的更多信息）：

$ kubectl apply -f common/nginx-config.yaml

如果在集群中启用了基于角色的访问控制（RBAC），请创建一个集群角色并将其绑定到服务帐户。 您必须是集群管理员才能执行此步骤：

$ kubectl apply -f rbac/rbac.yaml

现在部署入口控制器。该仓库中提供了两个部署的示例：Deployment和DaemonSet。如果您计划动态更改入口控制器副本的数量，请使用Deployment。使用DaemonSet可以在每个节点或节点子集上部署入口控制器。

如果你计划使用NGINX Plus部署清单，则必须更改YAML文件并指定自己的注册表和镜像。

对于 NGINX Deployment:
$ kubectl apply -f deployment/nginx-ingress.yaml
对于 NGINX Plus Deployment:
$ kubectl apply -f deployment/nginx-plus-ingress.yaml
对于 NGINX DaemonSet:
$ kubectl apply -f daemon-set/nginx-ingress.yaml
对于 NGINX Plus DaemonSet:
$ kubectl apply -f daemon-set/nginx-plus-ingress.yaml
验证入口控制器正在运行的东西:
$ kubectl get pods --namespace=nginx-ingress

如果创建了DaemonSet，则入口控制器的端口80和443将映射到容器正在运行的节点上的相同端口。要访问入口控制器，请使用运行着入口控制器的任何节点的这些端口和IP地址。如果部署了Deployment，请继续以下步骤。

对于Deployment方法，有两个用于访问入口控制器Pod的选项。您可以指示Kubernetes随机分配一个映射到入口控制器Pod的节点端口。这是类型为NodePort的服务。另一个选项是使用LoadBalancer类型创建服务。创建类型为LoadBalancer的服务时，Kubernetes会为给定的云平台（例如Amazon Web Services，Microsoft Azure和Google Cloud Compute）构建负载平衡器。

要创建类型为NodePort的服务，请使用以下命令：

$ kubectl create -f service/nodeport.yaml

要静态地配置为Pod打开的端口，请更改YAML并将属性nodePort：{port}添加到要打开的每个端口的配置中。

若要为Google Cloud Compute或Azure创建类型为LoadBalancer的服务，请使用以下代码：

$ kubectl create -f service/loadbalancer.yaml

要为Amazon Web Services创建类型为LoadBalancer的服务：

$ kubectl create -f service/loadbalancer-aws-elb.yaml

在AWS上，Kubernetes在启用PROXY协议的TCP模式下创建了经典的ELB。您必须将NGINX配置才能使用PROXY协议。为此，您可以将以下内容添加到前面提到的参考文件common/nginx-config.yaml的配置映射表中。

proxy-protocol: "True"
real-ip-header: "proxy_protocol"
set-real-ip-from: "0.0.0.0/0"

然后更新配置映射表:

$ kubectl apply -f common/nginx-config.yaml

现在，您可以通过其NodePort或通过向为它创建的负载均衡器发出请求来访问该Pod。

讨论

在撰写本文时，Kubernetes是容器编排和管理的领先平台。入口控制器是将流量路由到应用程序其余部分的边缘Pod。NGINX非常适合担任此角色，并使使用其注释进行配置变得简单。NGINX-Ingress项目通过DockerHub镜像提供了NGINX开源入口控制器，并通过一些步骤添加了NGINX Plus，以添加仓库证书和密钥。使用NGINX入口控制器启用Kubernetes集群可提供与所有NGINX相同的功能，但用Kubernetes网络和DNS的附加功能路由流量除外。

11.7 OpenShift路由器

问题

您正在OpenShift上部署您的应用程序，并希望使用NGINX作为路由。

解决方案

构建路由器镜像并将其上传到您的私有注册表。您可以在Origin Repository中找到镜像的源文件。在删除默认路由器之前，将您的路由器镜像推送到专用注册表很重要，因为它将使注册表不可用。

以管理员身份登录到OpenShift集群：

$ oc login -u system:admin

选择default项目：

$ oc project default

备份默认的路由器配置，以防您需要重新创建它：

$ oc get -o yaml service/router dc/router \
  clusterrolebinding/router-router-role \
  serviceaccount/router > default-router-backup.yaml

删除路由器：

$ oc delete -f default-router-backup.yaml

部署NGINX路由器：

$ oc adm router router --images={image} --type='' \
  --selector='node-role.kubernetes.io/infra=true'

在此示例中，{image}必须指向注册表中的NGINX路由器镜像。selector参数为将要部署路由器的节点指定标签选择器：node-role.kubernetes.io/infra=true。使用对您的环境有意义的选择器。

验证您的NGINX路由器容器是否正在运行：

$ oc get pods

您应该看到一个名为router-1-{string}的Router Pod。默认情况下，NGINX存根状态页面可通过运行路由器的节点的端口1936访问（您可以使用STATS_PORT环境变量来更改此端口）。要访问节点外部的页面，您需要为该节点的IPtables规则添加一个条目：

$ sudo iptables -I OS_FIREWALL_ALLOW -p tcp -s {ip range} \
  -m tcp --dport 1936 -j ACCEPT

将浏览器打开到http://{node-ip}:1936/stub_status以访问存根状态页面。

讨论

OpenShift路由器是绑定到应用程序(运行在OpenShift的)的外部请求入口点。路由器的工作是接收传入的请求，并将其定向到适当的应用程序容器。NGINX的负载平衡和路由功能使其成为用作OpenShift路由器的绝佳选择。为NGINX路由器替换默认的OpenShift路由器，使得作为OpenStack应用程序的入口的NGINX的所有功能和力量都能激活。