ayan.poddar/eShopOnContainers
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Updated 10.1 Deploying to Kubernetes (AKS and local) using Helm Charts (markdown)

Eduard Tomàs 2018-11-12 12:54:17 +01:00
parent 73880f2b97
commit 3e8ce1483a
1 changed files with 125 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

126
10.1-Deploying-to-Kubernetes-(AKS-and-local)-using-Helm-Charts.md

@ -219,4 +219,128 @@ marketing__PicBaseUrl: http://<url-of-the-storage>/
# Using Helm Charts to deploy eShopOnContainers to a local Kubernetes in Windows with 'Docker for Windows' # Using Helm Charts to deploy eShopOnContainers to a local Kubernetes in Windows with 'Docker for Windows'
TBD ## Additional pre-requisites
In addition to having Docker for Windows/Mac with Kubernetes enabled and having kubectl ayou also need the following pre-requisites:
### Install Helm
You need to have helm installed on your machine, and Tiller must be installed on the local Docker Kubernetes cluster. Once you have [Helm downloaded](https://helm.sh/) and installed on your machine you must:
1. Create the tiller service account, by running `kubectl apply -f helm-rbac.yaml` from `/k8s` folder
2. Install tiller and configure it to use the tiller service account by typing `helm init --service-account tiller`
### Install NGINX ingress controller
Docker local Kubernetes cluster do not have any ingress controller installed by default, so you need to install one. Any intress controller should work, but we have created the scripts for installing the NGINX ingress controller. To install it, just type (from `/k8s` folder):
1. `.\deploy-ingress.ps1`
2. `.\deploy-ingress-dockerlocal.ps1`
## Install eShopOnContainers using Helm
All steps need to be performed on `/k8s/helm` folder. The easiest way is to use the `deploy-all.ps1` script from a Powershell window:
```
.\deploy-all.ps1 -externalDns aks -aksName eshoptest -aksRg eshoptest -imageTag dev
```
This will install all the [eShopOnContainers public images](https://hub.docker.com/u/eshop/) with tag `dev` on the AKS named `eshoptest` in the resource group `eshoptest`. By default all infrastructure (sql, mongo, rabbit and redis) is installed also in the cluster.
Once the script is run, you should see following output when using `kubectl get deployment`:
```
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
eshop-apigwmm 1 1 1 1 4d
eshop-apigwms 1 1 1 1 4d
eshop-apigwwm 1 1 1 1 4d
eshop-apigwws 1 1 1 1 4d
eshop-basket-api 1 1 1 1 4d
eshop-basket-data 1 1 1 1 4d
eshop-catalog-api 1 1 1 1 4d
eshop-identity-api 1 1 1 1 4d
eshop-keystore-data 1 1 1 1 4d
eshop-locations-api 1 1 1 1 4d
eshop-marketing-api 1 1 1 1 4d
eshop-mobileshoppingagg 1 1 1 1 4d
eshop-nosql-data 1 1 1 1 4d
eshop-ordering-api 1 1 1 1 4d
eshop-ordering-backgroundtasks 1 1 1 1 4d
eshop-ordering-signalrhub 1 1 1 1 4d
eshop-payment-api 1 1 1 1 4d
eshop-rabbitmq 1 1 1 1 4d
eshop-sql-data 1 1 1 1 4d
eshop-webmvc 1 1 1 1 4d
eshop-webshoppingagg 1 1 1 1 4d
eshop-webspa 1 1 1 1 4d
eshop-webstatus 1 1 1 1 4d
```
Every public service is exposed through its own ingress resource, as you can see if using `kubectl get ing`:
```
eshop-apigwmm eshop.<your-guid>.<region>.aksapp.io <public-ip> 80 4d
eshop-apigwms eshop.<your-guid>.<region>.aksapp.io <public-ip> 80 4d
eshop-apigwwm eshop.<your-guid>.<region>.aksapp.io <public-ip> 80 4d
eshop-apigwws eshop.<your-guid>.<region>.aksapp.io <public-ip> 80 4d
eshop-identity-api eshop.<your-guid>.<region>.aksapp.io <public-ip> 80 4d
eshop-webmvc eshop.<your-guid>.<region>.aksapp.io <public-ip> 80 4d
eshop-webspa eshop.<your-guid>.<region>.aksapp.io <public-ip> 80 4d
eshop-webstatus eshop.<your-guid>.<region>.aksapp.io <public-ip> 80 4d
```
Ingresses are automatically configured to use the public DNS of the AKS provided by the "https routing" addon.
One step more is needed: we need to configure the nginx ingress controller that AKS has to allow more large headers. This is because the headers sent by identity server exceed the size configured by default. Fortunately this is very easy to do. Just type (from the `/k8s/helm` folder):
```
kubectl apply -f aks-httpaddon-cfg.yaml
```
Then you can restart the pod that runs the nginx controller. Its name is `addon-http-application-routing-nginx-ingress-controller-<something>` and runs on `kube-system` namespace. So run a `kubectl get pods -n kube-system` find it and delete with `kubectl delete pod <pod-name> -n kube-system`.
**Note:** If running in a bash shell you can type:
```
kubectl delete pod $(kubectl get pod -l app=addon-http-application-routing-nginx-ingress -n kube-system -o jsonpath="{.items[0].metadata.name}) -n kube-system
```
You can view the MVC client at http://[dns]/webmvc and the SPA at the http://[dns]/
## Customizing the deployment
### Using your own images
To use your own images instead of the public ones, you have to pass following additional parameters to the `deploy-all.ps1` script:
* `registry`: Login server for the Docker registry
* `dockerUser`: User login for the Docker registry
* `dockerPassword`: User password for the Docker registry
This will deploy a secret on the cluster to connect to the specified server, and all image names deployed will be prepended with `registry/` value.
### Using specific DNS
The `-externalDns` parameter controls the DNS bounded to ingresses. You can pass a custom DNS (like `my.server.com`), or the `aks` value to autodiscover the AKS DNS. For autodiscover to work you also need to pass which AKS is, using the `-aksName` and `-aksRg` parameters.
Autodiscovering works using Azure CLI under the hood, so ensure that Azure CLI is logged and pointing to the right subscription.
If you don't pass any external DNS at all, ingresses are'nt bound to any DNS, and you have to use public IP to access the resources.
### Not deploying infrastructure containers
If you want to use external resources, use `-deployInfrastructure $false` to not deploy infrastructure containers. However **you still have to manually update the scripts to provide your own configuration** (see next section).
### Providing your own configuration
The file `inf.yaml` contains the description of the infrastructure used. File is docummented so take a look on it to understand all of its entries. If using external resources you need to edit this file according to your needs. You'll need to edit:
* `inf.sql.host` with the host name of the SQL Server
* `inf.sql.common` entries to provide your SQL user, password. `Pid` is not used when using external resources (it is used to set specific product id for the SQL Server container).
* `inf.sql.catalog`, `inf.sql.ordering`, `inf.sql.identity`: To provide the database names for catalog, ordering and identity services
* `mongo.host`: With the host name of the Mongo DB
* `mongo.locations`, `mongo.marketing` with the database names for locations and marketing services
* `redis.basket.constr` with the connection string to Redis for Basket Service. Note that `redis.basket.svc` is not used when using external services
* `redis.keystore.constr` with the connection string to Redis for Keystore Service. Note that `redis.keystore.svc` is not used when using external services
* `eventbus.constr` with the connection string to Azure Service Bus and `eventbus.useAzure` to `true` to use Azure service bus. Note that `eventbus.svc` is not used when using external services