...
Goal: Minimize reliance on Ansible (for building in configurations)
Goal would be to Dockerize as much as possible
Considerations:
Have Kube YAML files as the primary source of configuration
Utilize ENVIRONMENT vars
“bake” other configs into Docker images
Use shared storage via Kubernetes volumes:
3rd party volumes are managed through YAML files (e.g NFS volume mounts or any persistent infrastructure mount options. see here)
Action Items:
Nginx:
Build Nginx with all OpenWhisk specific requirements (wsk, blackbox) pre-built into the Docker image.
- helps generate certificates
- create a Kube ConfigMap or Secrets Resource from those certs and a static Nginx.conf file. Where this nginx.conf file is specific to an environment
- Have yaml file(s) for the Kube Deployment and Service which uses the generated ConfigMap
Controller:
Provide the ability for the controller to receive updates that new invoker instances are able to be used.
This could be having invoker instances communicate directly to the controller <or>
The controller watches for updates to a key-value pairs it cares about in Consul.
Kafka:
On the initial startup, Kafka should register the “health” and “command” topics.
Ensure that Kafka is able to receive topic creation requests from Invoker instances
Zookeeper:
None?
Invoker:
Have the Invoker register its Kafka topics by interacting with Kafka.
Have the Invoker register itself with the Controller:
The Invoker must register itself directly to the controller <or>
The Invoker registers all key-value pair information about itself into Consul
Have only one Invoker instance be deployed to a Kube node and ensure that no other Kube Pods run alongside it as well
Consul:
One of two options:
Have consul exist as the central point where components register their information as they come up. Then all other components can receive updates from consul <or>
Remove consul from part of the OpenWhisk Deployment.
CouchDB:
Goal: Come up with a standardized way to setup and configure CouchDB as OW’s default document store.
Considerations:
This component is somewhat unique on the OpenWhisk deployment strategy as it only has to be done once and does not have rolling updates
Questions:
How can I configure CouchDB to with seed information for OpenWhisk?
Can we better leverage public Docker image by wrapping it for our needs (config)?
How can I have the OpenWhisk components talk to CouchDB?
Assumptions:
Over time we are working towards a “pluggable” document store approach, but this is beyond short-term scope. Despite this approach we still need to “Dockerize” our init/config as the “default”.
...