Replies: 2 comments 1 reply
-
A good way to do this is probably to create a long-lived token (or tokens) ahead of time, which would allow you to create as many agents as you want without needing to interact with the internal server api each time. You could then store a complete agent config secret in a ClusterResourceSet and have capi reconcile it on your downstream clusters. |
Beta Was this translation helpful? Give feedback.
-
@kralicky Thanks for your reply. The ultimate requirement here is to automate without human intervention the deployment of a rancher mgmt cluster, a rancher v2provisioned downstream opni server cluster, multiple v2provisioned opni agent clusters, and finally to install/register the opni agent on the rancher mgmt cluster. If I treat the opni server bootstrap credentials as long-lined assets, I can store them in our external secret store which simplifies pushing them between clusters as secrets. Is it possible to pre-generate the bootstrap credentials offline, store them in the Secret store, and then use them to pre-populate both the opni server and the opni agents? Or do I need to run a job on the opni server cluster after the install to create the bootstrap assets and push them to the Secret store via say an external secrets operator PushSecret? Your feedback is much appreciated. |
Beta Was this translation helpful? Give feedback.
-
When I use Rancher to provision a downstream cluster, I would like to automate installation of the opni-agent workload on the downstream cluster and also auto-register the opni-agent with the opni server . The Rancher highlander team seems to already be doing something similar by using cluster api to provision a downstream cluster and then using rancher-sandbox/rancher-turtles operator to register/import the downstream cluster with/into the Rancher server in this case.
As long as the opni server cluster and the opni agent clusters are managed by a common rancher management cluster, I would think that a rancher opni extension bundling a simple operator could be implemented that does something like the following:
opni bootstrap
api on the opni server cluster using kubeconfig of opni server cluster on behalf of opni agent downstream cluster. Maybe the operator would watch for Rancher Cluster CRs with a special label likerancher-opni-managed: true
to trigger these orchestration steps.WDYT?
Beta Was this translation helpful? Give feedback.
All reactions