...
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 NFS mountsKubernetes volumes:
3rd party volumes are managed through YAML files (all images mount existing NFS volume names)Use NFS as the “disk”, for updates that is easy as there is some NFS server that gets (un)mountede.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.
‘nginx.conf’ file should be generated when the Docker image comes up. This image should accept environment variables to setup deployment specific properties (i.e. URL for OpenWhisk Controller DNS address).
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 download all of the
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”.
...