You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Context:
At the current state, it is not easy at all to deploy this project on a remote cluster. We claim it is as easy as deploying Argo and applying our manifest but in fact, there are a series of challenges to overcome while doing that in order to achieve a perfectly working cluster, as we intended:
ArgoCD is required to be deployed on the argocd namespace, otherwise, our apps will fail to be deployed, as our manifests seem to have this value hardcoded
ArgoCD requires a special configuration to ensure our app-of-apps is deployed correctly, in the right order. Without this configuration, all our add-ons would not respect the order as well miss some configurations being made down the road.
In order to access the Kubernetes master API to provide a deployment context to the Github Action it is required to set up an OIDC connection, for example for AWS, it's not that easy to figure out which is the role to use, as well as which IAM permissions are required to make it work in the first place.
These are at the current state the challenges I faced with @LucaLanziani while we were trying to deploy this solution on an AWS EKS cluster and probably we missed some others that might happen down the road, but at the current state those are already some huge roadblocks we noticed that require immediate attention if we want to deliver an easy to use experience for DevOps onboarding this project, no matter their background.
The Solution:
First of all, it would be nice to identify if there is a way to abstract the OIDC connection layer to ensure it works cross-cloud and ideally even on bare metal. Once that has been figured out, an ideal solution would be to provide an easy-to-use script and/or a make command that would abstract this complexity and allow everyone to deploy this project on their target cloud environment ( AWS, Google, Azure, Alibaba, etc. ) with ease.
The Alternatives:
An alternative that could be considered but IMHO should be done meanwhile the full scripted solution is provided, is to create a series of documentation that would cover this aspect and help the DevOps operator to successfully deploy this solution on their intended cloud platform.
Detailed steps
N/A
Screenshots
N/A
Logs
No response
The text was updated successfully, but these errors were encountered:
Issue Type
Enhancement
Description
The Context:
At the current state, it is not easy at all to deploy this project on a remote cluster. We claim it is as easy as deploying Argo and applying our manifest but in fact, there are a series of challenges to overcome while doing that in order to achieve a perfectly working cluster, as we intended:
argocd
namespace, otherwise, our apps will fail to be deployed, as our manifests seem to have this value hardcodedapp-of-apps
is deployed correctly, in the right order. Without this configuration, all our add-ons would not respect the order as well miss some configurations being made down the road.These are at the current state the challenges I faced with @LucaLanziani while we were trying to deploy this solution on an AWS EKS cluster and probably we missed some others that might happen down the road, but at the current state those are already some huge roadblocks we noticed that require immediate attention if we want to deliver an easy to use experience for DevOps onboarding this project, no matter their background.
The Solution:
First of all, it would be nice to identify if there is a way to abstract the OIDC connection layer to ensure it works cross-cloud and ideally even on bare metal. Once that has been figured out, an ideal solution would be to provide an easy-to-use script and/or a make command that would abstract this complexity and allow everyone to deploy this project on their target cloud environment ( AWS, Google, Azure, Alibaba, etc. ) with ease.
The Alternatives:
An alternative that could be considered but IMHO should be done meanwhile the full scripted solution is provided, is to create a series of documentation that would cover this aspect and help the DevOps operator to successfully deploy this solution on their intended cloud platform.
Detailed steps
Screenshots
Logs
No response
The text was updated successfully, but these errors were encountered: