typositoire / concourse-helm3-resource Goto Github PK

Hello. Looks like a great resource. Slight hiccough I had was getting this working on a Concourse worker that is installed in Kubernetes itself. In this scenario, although I can point token_path at /var/run/secrets/kubernetes.io/serviceaccount/token, there is no way to provide ca path rather than ca value.

Given that Kubernetes service accounts have all the info to talk to the API server, it would be great if an example can be added and tested of a working K8S helm3 install.

FYI I'm trying this on EKS with Concourse installed via its own helm chart, and installing a custom helm chart in a separate namespace on the same demonstration K8S cluster.

Happy to discuss this and to work on it myself. I've reached out to you on the Concourse Discord too to discuss options.

Thanks!

I would like to submit a modification request to add a "helm rollback" feature option to the "put" action in helm-3-resources. This will be helpful in case there is a need to rollback a published version.

With the extra work I'm putting into lots of stuff and other things it is clear that I can't maintain this to a level I'm happy with. I'd like to call for a new maintainer. Please manifest yourself!

Seems to be that the parameter replace is not implemented in the code

Rather than requiring cluster_ca for https can we add the --insecure-skip-tls-verify flag to the resource config?

the namespace_overwrite param doesn't get loaded in the out when its passed as a string.

PR #15 fixes this problem

Starting v1.22.0, this resource check started failing with error: Unable to connect to the server: x509: certificate signed by unknown authority

Concourse Version: 7.1.1
Concourse Worker OS: Ubuntu 20.4 LTS

If I downgrade to version v1.21.0, I get following error:
/opt/resource/common.sh: line 43: /dev/stderr: Permission denied
and if I set privileged=true on resource type, it works.

Problem
I have a boolean helm variable with a default value of true. I want to override this value on a specific environment to be false.

Version
1.9.2

Description
When defining an override for a boolean value as false then this override is not present as a --set parameter when helm is called.

Example

override_values:
  - key: global.isEnabled
     value: false
  - key: global.isDisabled
     value: true

Leads to a helm statement like this:

helm upgrade mychart ... --set global.isDisabled=true

I would expect:

helm upgrade mychart ... --set global.isEnabled=false --set global.isDisabled=true

I will be soon starting on implementing the helm test feature, which is right now "To be Implemented".
I am curious to know if you or anyone who have forked this repo are on the way to put in an implementation any time soon?

Do you have any ideas/directions around the implementation?

https://helm.sh/docs/helm/helm_delete/

Hiya,

I just had a quick feature request. I use Google Cloud Platform to host Kubernetes (GKE), and the typical way to authenticate is via the gcloud command. There is an active PR for the Linkyard resource to add the functionality: linkyard/concourse-helm-resource#145

Would there be any possibility of including this in the resource? I'd be happy to PR the changes with @shashankkoppar's permission

Thanks!

This is an open question for the Community.

Should I build this resource against the last 3 versions of kubectl? Only latest? What's your use-case and needs?

Resource should be able to do helm dep build

When running Concourse configured with the Kubernetes secret credential source, I can use the secret that gets dynamically generated for each cluster ServiceAccount to authenticate this resource to the cluster. The dynamic secret conveniently provides the token and CA certificate required by the resource and is easy to access with Concourse. For example, I should be able to do:

resources:
  - name: helm-release
    type: helm
    source:
      namespace: ((concourse-deployer-token.namespace))
      cluster_url: "https://kubernetes.default.svc"
      cluster_ca: ((concourse-deployer-token."ca.crt"))
      token: ((concourse-deployer-token.token))

However this currently isn't possible because the resource expects a Base64-encoded certificate, and ((concourse-deployer-token."ca.crt")) evaluates to the unencoded PEM.

Maybe we could have a new parameter like cluster_ca_pem that accepts the unencoded PEM? I'm happy to raise a PR to implement this if it seems suitable.

When setting stable_repo to false it still add the stable repo, could be caching issue or base image that adds it ?

A deployment fails without specifying a release name. This is to the fact that Helm3 requires the --generate-name flag to be set IF the name of the release is omitted. Currently the flag ISN'T set if the release is empty

https://github.com/jkroepke/helm-secrets

So it can decrypt and run Helm upgrade / install on the fly

Hi there

I've run into an issue when my resource is defined without a URL/creds for my k8s cluster, which are instead provided via the kubeconfig_path param on a put as follows:

resources:
- name: minibroker
  type: helm
  source:
    release: minibroker
    repos:
      - name: minibroker
        url: https://minibroker.blob.core.windows.net/charts

...
jobs:
 - put: minibroker
    params:
      chart: minibroker/minibroker
      kubeconfig_path: kubeconfig/kubeconfig.yaml

With this configuration my put succeeds but then the resource box leaving my job shows up orange in the Concourse UI, as the resource check errors as follows:

I might not have quite understood how I should configure the resource, but perhaps the issue I'm hitting is that the function setup_kubernetes [always exits 1 if neither a cluster URL nor kubeconfig are defined in the resource's source block].

In our case we particularly want to provide a kubeconfig file as a put param because we construct that file earlier in the same pipeline job from terraform outputs.

It looks like I missed something in my PR #40 because base64 -d still tries to decode the unencoded CA PEM and produces garbage to /dev/stdout (weird behaviour, IMO). This leads to an error from Helm:

Unable to connect to the server: x509: certificate signed by unknown authority

Sorry about that, I'll raise a PR to fix this.

In the Dockerfile, we're using both

Not sure if anyone else has seen this but getting this error when trying to deploy:

Initializing helm...
09:01:15
version.BuildInfo{Version:"v3.0.2", GitCommit:"19e47ee3283ae98139d98460de796c1be1e3975f", GitTreeState:"clean", > GoVersion:"go1.13.5"}
09:01:16
Error: looks like "https://kubernetes-charts.storage.googleapis.com" is not a valid chart repository or cannot be reached: > failed to fetch https://kubernetes-charts.storage.googleapis.com/index.yaml : 403 Forbidden

I have tried setting stable_repo to false and get this error and this worked for our on-prem Kubernetes deploy, however it did not work in EKS. I have tried setting stable_repos to the default https://charts.helm.sh/stable but that also does not work. I can add the stable repo if I highjack the container. I am not using "https://kubernetes-charts.storage.googleapis.com" in any of my code but I also don't see anywhere it used anywhere here.

The last successful deploy in EKS was the first week of December and I have made no changes to my pipeline in that time.

Rancher services account uses username and password. While tokens are possible, they are a pain to refresh in Vault.

Initializing helm...
version.BuildInfo{Version:"v3.8.0", GitCommit:"d14138609b01886f544b2025f5000351c9eb092e", GitTreeState:"clean", GoVersion:"go1.17.5"}
Error: could not find protocol handler for:

When adding version to params, concourse fails the build with the following error

invalid payload (missing version if chart is from repository.

Should this be using -n and not -z to check if its empty, instead of checking that its got a value.

This is the job i have added it to, when removing the version it installs fine. However I want to explicitly set the version for each chart.

- name: external-dns
  plan:
  - get: helm-config
  - put: helm-external-dns
    params:
      chart: stable/external-dns
      values: helm-config/helm/engineering/external-dns.yml
      version: 2.14.3

https://github.com/jkroepke/helm-secrets

in is conspicuously unimplemented. I feel like a natural fit here is to run helm pull on get: helmchart-resource, producing as output a directory containing the tgz. Perhaps even with a param to give the unzipped tarball instead/in addition to.

I have found an issue in helm where I get this error with the helm upgrade --install command:

coalesce.go:196: warning: cannot overwrite table with non table for defaultNodeSelector (map[])
coalesce.go:122: Conflict: cannot merge map onto non-map for "defaultNodeSelector". Skipping.
.
.
.
coalesce.go:196: warning: cannot overwrite table with non table for defaultNodeSelector (map[])
coalesce.go:133: key defaultNodeSelector is table. Skipping

The full command being run:

Running command helm upgrade --install istio /tmp/build/put/istio-repo/ci/helm-charts/istio --namespace=istio-system -f /tmp/build/put/istio-repo/ci/helm-charts/istio/values-istio-dev.yaml --set-string global.defaultNodeSelector="my-node-string" | tee /tmp/log

I have found if I run the command as helm install only, it works:

helm install istio /tmp/build/put/istio-repo/ci/helm-charts/istio --namespace=istio-system -f /tmp/build/put/istio-repo/ci/helm-charts/istio/values-istio-dev.yaml --set-string global.defaultNodeSelector."my-node-sting" | tee /tmp/log

Is there a way to add an option to run helm install rather than helm upgrade --install?

Allows to use helm set-file option

Been running into this issue for a few days, not sure what is happening.

• helm 3.8.0
• go 1.17.5

resource_type

  -
    name: helm
    type: docker-image
    source:
      repository: ghcr.io/typositoire/concourse-helm3-resource
      tag: v1.19.1

resource

 -
    name: some-helm-repo
    type: helm
    check_every: 10s
    source:
      cluster_url: ((common-secrets.control_plane))
      cluster_ca: ((common-secrets.cad))
      token: ((common-secrets.token))
      repos:
        -
          name: company
          url: 'https://helm.repo/chartrepo/library'
          username: ((common-secrets.harbor_username))
          password: ((common-secrets.harbor_password))
        -
          name: bitnami
          url: 'https://charts.bitnami.com/bitnami'

task

      - put: some-helm-repo
        params:
          chart: bitnami/redis
          values: community-helm-values-bucket-redis/redis.yml
          version: 14.4.0
          atomic: true
          namespace: x61e3ff9f
          timeout: 3m0s
          show_diff: true
          release: redis

Output in concourse:

Resource setup successful.

Installing redis

Release diff:

Error: unknown command "diff" for "helm"
Run 'helm --help' for usage.

So far I tried:

• resource type without tag (original state)
• using resource type with tag v1.20.0
• using resource type with tag v1.19.1

Somehow I feel this is an issue higher up, but I can't really pin it. Advice would really be great 🙏

We do have the logic to set max_history but we don't parse any parameter.

Hi,
Creating this issue to fix two things.
1) Helm 3 removed the option of purging a delete and now it is done by default.
ISSUE: helm/helm#5804.
2) Also, since the releases can be installed in different namespaces, helm delete should take the namespace as a flag else it won't find it cause it checks the default namespace.
These two fixes requires changing the out.sh and README.md.

@Typositoire I would be happy to contribute to this by creating a PR. :) Let me know your thoughts. Great work!!

We should probably handle the last 3 versions of Kubernetes to avoid: version difference between client and server exceeds the supported minor version skew of +/- 1

Ideally we shouldn't triple the tags 😬