[incubator-openwhisk-deploy-kube] branch master updated: reorganize ingress documentation to group by ingress instead of cloud provider. (#256)
This is an automated email from the ASF dual-hosted git repository. markusthoemmes pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/incubator-openwhisk-deploy-kube.git The following commit(s) were added to refs/heads/master by this push: new aed807c reorganize ingress documentation to group by ingress instead of cloud provider. (#256) aed807c is described below commit aed807cecebd63de2f6b24988822711170e34ee7 Author: David Grove AuthorDate: Wed Jul 18 10:50:08 2018 -0400 reorganize ingress documentation to group by ingress instead of cloud provider. (#256) --- docs/ingress.md | 100 +++- 1 file changed, 62 insertions(+), 38 deletions(-) diff --git a/docs/ingress.md b/docs/ingress.md index c7731a4..73c32d8 100644 --- a/docs/ingress.md +++ b/docs/ingress.md @@ -28,38 +28,35 @@ will use in the `helm install` command. You will need to define values for at least `whisk.ingress.type` and `whisk.ingress.api_host_name` and `whisk.ingress.api_host_port`. -Unfortunately, the exact details of configuring an Ingress vary across -cloud providers. The detailed instructions -[below](#possible-ingress-types) describe multiple possible Ingress -configurations. We welcome contributions from the community to +Unfortunately, the exact details of configuring an Ingress can vary +across cloud providers. The detailed instructions describe multiple +possible Ingress configurations with specific details for some public +cloud providers. We welcome contributions from the community to describe how to configure Ingress for additional cloud providers. If you are deploying on minikube, use the NodePort instructions below. -# Possible Ingress Types - -## NodePort +# NodePort NodePort is the simplest type of Ingress and is suitable for use with minikube and single node clusters that do not support more advanced ingress options. Deploying a NodePort ingress will expose a port on each Kubernetes worker node for OpenWhisk's nginx service. + In this Ingress, TLS termination will be handled by OpenWhisk's `nginx` service and will use self-signed certificates. You will need to invoke `wsk` with the `-i` command line argument to bypass certificate checking. -First, obtain the IP address of the Kubernetes nodes. If you are -using minikube, use the command +## Setting up NodePort on minikube + +First, obtain the IP address of the single Kubernetes worker node. ```shell minikube ip ``` -otherwise use -``` -kubectl get nodes -``` +This will return an ip address, for example `192.168.99.100`. -Next pick an unassigned port (eg 31001) and define mycluster.yaml as +Next pick an unassigned port (eg 31001) and define `mycluster.yaml` as ```yaml whisk: ingress: @@ -71,18 +68,15 @@ nginx: httpsNodePort: 31001 ``` -## IBM Cloud - -### IBM Cloud Lite cluster +## Setting up NodePort on an IBM Cloud Lite cluster -The only available ingress method for a Lite cluster is to use a -NodePort (see above). Obtain the Public IP address of the sole worker -node by using the command - ``` +The only available ingress method for an IBM Cloud Lite cluster is to +use a NodePort. Obtain the Public IP address of the sole worker node +by using the command +```shell bx cs workers - ``` -Then define mycluster.yaml as - +``` +Then define `mycluster.yaml` as ```yaml whisk: ingress: @@ -94,12 +88,45 @@ nginx: httpsNodePort: 31001 ``` -### IBM Cloud standard cluster +# Standard -This type of cluster can support a more advanced ingress style that -does not use self-signed certificates for TLS termination (you can use -`wsk` instead of `wsk -i`). You will need to determine the values for - and for your cluster by running the command +Many cloud providers will support creating a Kubernetes Ingress that +may offer additional capabilities features such as TLS termination, +load balancing, and other advanced features. We will call this a +`standard` ingress and provide a parameterized ingress.yaml as part of +the Helm chart that will create it using cloud-provider specific +parameters from your `mycluster.yaml`. Generically, your +`mycluster.yaml`'s ingress section will look something like: +```yaml +whisk: + ingress: +api_host_name: ** +api_host_port: 443 +api_host_proto: https +type: standard +domain: ** +tls: + enabled: ** + secretenabled: ** + createsecret: ** + secretname: ** + ** +annotations: + ** +``` + +Note that if you can setup an ingress that does not use self-signed +certificates for TLS termination you will be able to use `wsk` instead +of `wsk -i` for cli operations. + +## IBM Cloud standard cluster + +This cluster type does not use self-signed certificates for TLS +termination and can be configured with additional annotations to +fine tune ingress performance. + +First, determine the values for and for +your cluster by running the command:
[incubator-openwhisk-deploy-kube] branch master updated: Document expectations for PersistentVolume creation (#245)
This is an automated email from the ASF dual-hosted git repository. markusthoemmes pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/incubator-openwhisk-deploy-kube.git The following commit(s) were added to refs/heads/master by this push: new 40a45ce Document expectations for PersistentVolume creation (#245) 40a45ce is described below commit 40a45ced2cdc259ecefe1921d8097861fe241cff Author: David Grove AuthorDate: Wed Jul 18 10:49:54 2018 -0400 Document expectations for PersistentVolume creation (#245) Fixes #244. --- README.md| 3 ++- docs/configurationChoices.md | 9 +++-- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 1e83747..e32f30c 100644 --- a/README.md +++ b/README.md @@ -39,8 +39,9 @@ This repository can be used to deploy OpenWhisk to a Kubernetes cluster. ### Requirements Several requirements must be met for OpenWhisk to deploy on Kubernetes. -* [Kubernetes](https://github.com/kubernetes/kubernetes) version 1.8+. However, multiple minor releases of Kubernetes, including 1.8.9 and 1.9.4 will not work for OpenWhisk due to bugs with volume mount subpaths (see[[1](https://github.com/kubernetes/kubernetes/issues/61076)]. This bug will surface as a failure when deploying the nginx container. +* [Kubernetes](https://github.com/kubernetes/kubernetes) version 1.8+. However, multiple minor releases of Kubernetes, including 1.8.9 and 1.9.4 will not work for OpenWhisk due to bugs with volume mount subpaths (see[[kubernetes-61076](https://github.com/kubernetes/kubernetes/issues/61076)]). This bug will surface as a failure when deploying the nginx container. * The ability to create Ingresses to make a Kubernetes service available outside of the cluster so you can actually use OpenWhisk. +* If you enable persistence (see [docs/configurationChoices.md](./docs/configurationChoices.md)), either your cluster is configured to support [Dynamic Volume Provision](https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/) or you must manually create any necessary PersistentVolumes when deploying the Helm chart. * Endpoints of Kubernetes services must be able to loopback to themselves (the kubelet's `hairpin-mode` must not be `none`). ### Using Minikube diff --git a/docs/configurationChoices.md b/docs/configurationChoices.md index db8bfe4..30eed7c 100644 --- a/docs/configurationChoices.md +++ b/docs/configurationChoices.md @@ -86,12 +86,17 @@ redis: size: 256Mi storageClass: default ``` +If you are deploying to `minikube`, use the storageClass `standard`. If you are deploying on a managed Kubernetes cluster, check the cloud provider's documentation to determine the appropriate `storageClass` and `size` to request. -*Limitation* Currently the persistent volume support assumes that the -`replicaCount` of the deployment using the persistent volume is 1. +Note that the Helm charts do not explicitly create the +PersistentVolumes to satisfy the PersistentVolumeClaims they +instantiate. We assume that either your cluster is configured to +support [Dynamic Volume Provision](https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/) +or that you will manually create any necessary PersistentVolumes when +deploying the Helm chart. ### Invoker Container Factory
[incubator-openwhisk-deploy-kube] branch master updated: ingress.md information about google cloud DNS (#259)
This is an automated email from the ASF dual-hosted git repository. dgrove pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/incubator-openwhisk-deploy-kube.git The following commit(s) were added to refs/heads/master by this push: new fb8c879 ingress.md information about google cloud DNS (#259) fb8c879 is described below commit fb8c879ef43d57c683b9983ba7bb136c9ac2e55f Author: Carlos Duque AuthorDate: Wed Jul 18 15:18:55 2018 +0100 ingress.md information about google cloud DNS (#259) * Updated ingress.md documentation with link to google cloud documentation on DNS --- docs/ingress.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/ingress.md b/docs/ingress.md index 2604849..c7731a4 100644 --- a/docs/ingress.md +++ b/docs/ingress.md @@ -162,7 +162,9 @@ whisk: ### Google Cloud with nginx ingress This type of installation allows the same benefits as the IBM Cloud standard cluster. -According to your nginx ingress settings you can define a value of your choice. + +According to your nginx ingress settings you can define a value of your choice. Check the official Google Cloud documentation here: https://cloud.google.com/kubernetes-engine/docs/tutorials/configuring-domain-name-static-ip. As stated you can create a domain of the type: `openwhisk..com` + You can choose to create a tls secret for that and provide values for and in base64. To generate the values for and you can use the openssl tool:
[CONF] OpenWhisk > OpenWhisk future architecture
Title: Message Title There's 1 new edit on this page OpenWhisk future architecture Markus Thömmes edited this page Here's the version comment Markus Thömmes edited at 09:34 AM Added headings for diagrams. Here's what changed: ... Kafka is still in the picture to handle overload scenarios (see Invoker Activation Queueing Change). General dependencies between components Drawio border true viewerToolbar true fitWindow false diagramName arch simpleViewer false width diagramWidth 796 revision 3 Full lifecycle of invocation and container creation Drawio border true viewerToolbar true fitWindow false diagramName flow simpleViewer false width diagramWidth 563 revision 2 ... Edge case: If an action only has a very small amount of containers (less than there are Controllers in the system), we have a problem with the method described above. Since the front-door schedules round-robin or least-connected, it's impossible to decide to which Controller the request needs to go to hit that has a container available.In this case, the other Controllers (who didn't get a container) act as a proxy and send the request to a Controller that actually has a container (maybe even via HTTP redirect). The ContainerManager decides which Controllers will act as a proxy in this case, since its the instance that distributes the containers. Edge case diagram Drawio border true viewerToolbar true fitWindow false diagramName edgecase simpleViewer false width diagramWidth 451 revision 2 ... Go to page history View page Stop watching space • Manage notifications This message was sent by Atlassian Confluence 6.9.0
[incubator-openwhisk] branch master updated: Limit TLS protocols used for kafka and controller. (#3881)
This is an automated email from the ASF dual-hosted git repository.
cbickel pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-openwhisk.git
The following commit(s) were added to refs/heads/master by this push:
new 9afaf7b Limit TLS protocols used for kafka and controller. (#3881)
9afaf7b is described below
commit 9afaf7be1a9c5cf69ad567e416d46cce351ee01a
Author: Vadim Raskin
AuthorDate: Wed Jul 18 08:49:41 2018 +0200
Limit TLS protocols used for kafka and controller. (#3881)
* Limit TLS protocols used for kafka and controller
* Move protocols property into group_vars
---
ansible/group_vars/all | 2 ++
ansible/roles/kafka/tasks/deploy.yml| 1 +
core/controller/src/main/resources/application.conf | 18 ++
3 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/ansible/group_vars/all b/ansible/group_vars/all
index 729a683..19a7c9f 100644
--- a/ansible/group_vars/all
+++ b/ansible/group_vars/all
@@ -131,6 +131,8 @@ kafka:
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
+protocols:
+- TLSv1.2
protocol: "{{ kafka_protocol_for_setup }}"
version: 0.11.0.1
port: 9072
diff --git a/ansible/roles/kafka/tasks/deploy.yml
b/ansible/roles/kafka/tasks/deploy.yml
index 8f195fe..436fcc9 100644
--- a/ansible/roles/kafka/tasks/deploy.yml
+++ b/ansible/roles/kafka/tasks/deploy.yml
@@ -51,6 +51,7 @@
"KAFKA_SSL_TRUSTSTORE_PASSWORD": "{{ kafka.ssl.keystore.password }}"
"KAFKA_SSL_CLIENT_AUTH": "{{ kafka.ssl.client_authentication }}"
"KAFKA_SSL_CIPHER_SUITES": "{{ kafka.ssl.cipher_suites | join(',') }}"
+ "KAFKA_SSL_ENABLED_PROTOCOLS": "{{ kafka.ssl.protocols | join(',') }}"
# The sed script passed in CUSTOM_INIT_SCRIPT fixes a bug in the
wurstmeister dcoker image
# by patching the server.configuration file right before kafka is started.
# The script adds the missing advertized hostname to the
advertised.listener property
diff --git a/core/controller/src/main/resources/application.conf
b/core/controller/src/main/resources/application.conf
index 77ce527..f0a7877 100644
--- a/core/controller/src/main/resources/application.conf
+++ b/core/controller/src/main/resources/application.conf
@@ -73,11 +73,16 @@ akka {
}
}
-ssl-config.enabledCipherSuites = [
- "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
- "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
- "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
-]
+ssl-config {
+ enabledCipherSuites = [
+"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
+"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
+"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
+ ]
+ enabledProtocols = [
+"TLSv1.2"
+ ]
+}
whisk{
# tracing configuration
@@ -85,6 +90,3 @@ whisk{
component = "Controller"
}
}
-
-
-
