sassoftware / viya4-monitoring-kubernetes

Provides simple scripts and customization options to deploy monitoring, alerts, and log aggregation for Viya 4 running on Kubernetes
Apache License 2.0
56 stars 32 forks source link

Deploy viya4 monitor offline(Grafana/Kibana) #463

Closed Carmelo07anthony closed 1 year ago

Carmelo07anthony commented 1 year ago

Hi guys, appreciate the work for this git project for SAS Viya 4 monitor, however, is there any chance I could deploy this project without internet? I've try to modified all files that contain https request (helm local repo, wget img...etc) but rather seems failure, it would be wonderful if some of you have any idea or hint for this one Thanks

gsmith-sas commented 1 year ago

Hello @Carmelo07anthony,

Support for "dark" sites (i.e. sites without internet access) is something we want to add to the project but have not had a chance to do that yet. Last summer, we did some internal testing to understand what is needed to support using a private (container) image registry/repository. We were able to get that working but had to make changes to files other than the various Helm user values yaml files.

And, as it sounds like you have discovered, adding fill support for sites with no access to the Internet will probably require even more changes. Can you provide more information about what you have done and the problems you are running into? That would help us provide some better advice on how to overcome the obstacles you are facing.

Thanks, Greg p.s. If you are a SAS employee, feel free to contact me via internal e-mail.

Carmelo07anthony commented 1 year ago

Hello @Carmelo07anthony,

Support for "dark" sites (i.e. sites without internet access) is something we want to add to the project but have not had a chance to do that yet. Last summer, we did some internal testing to understand what is needed to support using a private (container) image registry/repository. We were able to get that working but had to make changes to files other than the various Helm user values yaml files.

And, as it sounds like you have discovered, adding fill support for sites with no access to the Internet will probably require even more changes. Can you provide more information about what you have done and the problems you are running into? That would help us provide some better advice on how to overcome the obstacles you are facing.

Thanks, Greg p.s. If you are a SAS employee, feel free to contact me via internal e-mail.

Hi sir, my thoughts are creating local helm repository and store image for v4m locally however, I can download it to local repository but chart yaml inside seems to capture online helm charts again. This might cause loop when installing component using helm for container image seems rather easy at this point since I only need to store them locally and change the destination

gsmith-sas commented 1 year ago

@Carmelo07anthony As you have discovered, we explicitly identify the Helm repository in our calls to Helm. So that is why you cannot use a local Helm repo. I have made a note that we will need include support for a local Helm repo when we support deploying to "dark" sites, i.e. sites with no internet access. Our deployment scripts also make "helm repo update" that will probably need to be tweaked so they are not called when run in such an environment.

As for supporting a private container registry, the good news is that almost all of the Helm charts allow you to point to your own container registry rather than the public ones we default to. However, there are few cases where someone would need to modify other files to point to a private container registry. For example, the Event Router component is not deployed using Helm, so a file in our repo (logging/eventrouter/eventrouter.yaml) would need to be modified. And, as a second example, for OpenSearch, an initContainer uses busybox but identifying the location of that image is not part of the Helm chart definition. This means someone would need to update the another file (logging/opensearch/opensearch_helm_values.yaml) in the repo to point to a private container registry. There are a couple of other examples where something similar is needed if someone wants to deploy the metric monitoring components (e.g. Grafana, Prometheus, etc.) with TLS enabled.

I am sorry we do not currently support deploying in such an environment. However, we hope to deliver that functionality later this year.