...
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 already happens by default. Currently Kafka can receive new topics to automatically be created and used.
Need to make sure we use stateful sets so controller has unique names.
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”.
...