imgproxy / imgproxy-helm Goto Github PK

If we want to manage secrets like AWS credentials, bearer token, etc by an external secrets manager like Valut, Sealed secrets controller we need the chart to be able to attach external K8s secret with these values.

When HPA is enabled Helm upgrades fail with the following error:

failed to create patch: unable to find api field in struct HorizontalPodAutoscalerSpec for the json field "behavior"

The deployed YAML looks like this:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  creationTimestamp: "2021-09-30T10:17:01Z"
  labels:
    app: imgproxy
    chart: imgproxy-0.8.1
    heritage: Helm
    release: imgproxy
  managedFields:
  - apiVersion: autoscaling/v2beta2
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:labels:
          .: {}
          f:app: {}
          f:chart: {}
          f:heritage: {}
          f:release: {}
      f:spec:
        f:behavior:
          .: {}
          f:scaleDown:
            .: {}
            f:policies: {}
            f:selectPolicy: {}
            f:stabilizationWindowSeconds: {}
          f:scaleUp:
            .: {}
            f:policies: {}
            f:selectPolicy: {}
            f:stabilizationWindowSeconds: {}
        f:maxReplicas: {}
        f:metrics: {}
        f:minReplicas: {}
        f:scaleTargetRef:
          f:apiVersion: {}
          f:kind: {}
          f:name: {}
    manager: Go-http-client
    operation: Update
    time: "2021-09-30T10:17:01Z"
  - apiVersion: autoscaling/v1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          f:autoscaling.alpha.kubernetes.io/conditions: {}
          f:autoscaling.alpha.kubernetes.io/current-metrics: {}
      f:status:
        f:currentCPUUtilizationPercentage: {}
        f:currentReplicas: {}
        f:desiredReplicas: {}
    manager: kube-controller-manager
    operation: Update
    time: "2021-09-30T10:17:17Z"
  name: imgproxy-autoscaling
  namespace: imgproxy
  ...
spec:
  behavior:
    scaleDown:
      policies:
      - periodSeconds: 15
        type: Percent
        value: 100
      selectPolicy: Max
      stabilizationWindowSeconds: 300
    scaleUp:
      policies:
      - periodSeconds: 15
        type: Pods
        value: 4
      - periodSeconds: 15
        type: Percent
        value: 100
      selectPolicy: Max
      stabilizationWindowSeconds: 300
  maxReplicas: 3
  metrics:
  - resource:
      name: cpu
      target:
        averageUtilization: 80
        type: Utilization
    type: Resource
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: imgproxy
status:
  conditions:
  - lastTransitionTime: "2021-09-30T10:17:17Z"
    message: recent recommendations were higher than current one, applying the highest
      recent recommendation
    reason: ScaleDownStabilized
    status: "True"
    type: AbleToScale
  - lastTransitionTime: "2021-09-30T10:17:17Z"
    message: the HPA was able to successfully calculate a replica count from cpu resource
      utilization (percentage of request)
    reason: ValidMetricFound
    status: "True"
    type: ScalingActive
  - lastTransitionTime: "2021-09-30T10:46:55Z"
    message: the desired count is within the acceptable range
    reason: DesiredWithinRange
    status: "False"
    type: ScalingLimited
  currentMetrics:
  - resource:
      current:
        averageUtilization: 0
        averageValue: 2m
      name: cpu
    type: Resource
  currentReplicas: 1
  desiredReplicas: 1

Is that maybe a specific issue with our Helm version or can you reproduce this behavior in your environment in Helm upgrades as well?

@ has just updated the Configuration part of the documentation.
Please, check the difference and make the necessary changes in the Helm chart.

Good morning,

I'm facing an issue with pathPrefix value to set the IMGPROXY_PATH_PREFIX environment variable. First of all, it's not documented in Readme.md at all though it exists in the template. Also, when I've tried to use it, it seems to break liveness/readiness probs of the Pod, since now the health endpoint is most likely also running at pathPrefix/health not just at /health as defined in the template.

@ has just updated the Configuration part of the documentation.
Please, check the difference and make the necessary changes in the Helm chart.

Is there a reason behind having a 1 CPU limit for imgproxy?

Seems like it's better to leave it without any default values and let the users set the resources & requests, due to let's say removing CPU limits.

https://home.robusta.dev/blog/stop-using-cpu-limits/

Since I wanted to remove CPU limits and there isn't a nice way to do that atm.

Hi, ImplementationSpecific path type with AWS ELB Controllers works as Exact type rather than Prefix. Could you provide the ability to change path type with values? ImplementationSpecific default should fix a problem with BC.

It's not obvious that I need to set enablePrometheus: true to add containerPort to deployment. Thus it takes some time to find out why Prometheus not receiving metrics :)

I'll be more than happy to help with pr.

@ has just updated the Configuration part of the documentation.
Please, check the difference and make the necessary changes in the Helm chart.

Hi 👋🏻
I'm testing imgproxy-helm chart, I configured the persistence by habits but… what's its usage? After a dozen of tests I don't see anything written in it and I see no option related to it.
Is it only to act like image source?
Thank you for your precisions.

otherwise it will cause conflict when using tools like anthos config sync. where deployment.spec.replicas will be constantly changed by both HorizontalPodAutoscaler and config sync

@ has just updated the Configuration part of the documentation.
Please, check the difference and make the necessary changes in the Helm chart.

Hello, dealing with some work on K8s cluster with imgproxy 0.7.9 installed via helm. I had some issues replacing the nodes because the PodDisruptionBudget exists:

$ kubectl get pdb -n tools
NAME                    MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
imgproxy-imgproxy-pdb   N/A             N/A               0                     60d

When I checked the documentation, the default is "false":
https://github.com/imgproxy/imgproxy-helm/tree/0.7.9

To my surprise, I have no "resources.podDisruptionBudget.enabled" set to "true" in the values.yaml in the IaC repository so I checked the values.yaml in your helm repo and found this:

...
  podDisruptionBudget:
    enabled: true
...

Source:
https://github.com/imgproxy/imgproxy-helm/blob/0.7.9/imgproxy/values.yaml

From what I understand from the documentation:
https://helm.sh/docs/chart_template_guide/values_files/

First values are populated from values.yaml in the helm repo, then patched with whatever is supplied on command line(either by --set or -f ), therefore, the documentation for this chart seems to be wrong. PodDisruptionBudget is enabled by default.

@ has just updated the Configuration part of the documentation.
Please, check the difference and make the necessary changes in the Helm chart.

Good day,

I am running into an issue trying to expose both the ingress and the health ingress on static IP addresses. Looking at the templates, they both share the same ingress.annotations. This makes it impossible to expose both ingresses on static IP addresses. You can expose the ingress only on a static IP address but then you can no longer use the health ingress.

Would it be possible to have a separate ingress.health.annotations for the health ingress? To avoid any breaking changes, it could just default back to ingress.annotations if not specified.

Could you please advise if maybe there's another way of going about it? Thanks.

Regards

Hey, i see that abs, s3 and gcs is supported by imgproxy, but only s3 and gcs in the helm chart. Any plans to support Azure blobstorage?

/ Nico

v0.8.18
Pod not starting, log:
FATAL [2022-07-29T12:13:43Z] Unknown image format: true

v0.8.17 - OK

@ has just updated the Configuration part of the documentation.
Please, check the difference and make the necessary changes in the Helm chart.

Hi there,
I'm trying to deploy:

$ helm fetch https://helm.imgproxy.net/
Error: Failed to fetch https://helm.imgproxy.net/ : 404 Not Found

please fix it
Thank you!

Hello!

Our use case for this Helm chart includes the creation of a Kubernetes service account to leverage AWS IAM Role Binding (https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html).

We use IAM Roles and Policies to grant access to S3 buckets to imgproxy pods.

In fact, I have a locally ready branch with all the resources needed, but obviously I am not able to create a new branch on the repo to create a PR :)

Thanks for your efforts!

@ has just updated the Configuration part of the documentation.
Please, check the difference and make the necessary changes in the Helm chart.

It appears that kustomize is unable to handle the <<: syntax present in the newer chart:

Error: map[string]interface {}{"apiVersion":"v1", "kind":"ServiceAccount", "metadata":map[string]interface {}{"labels":map[interface {}]interface {}{"imgproxy":"true", "test": "test"}, "name":"imgproxy-service-account", "namespace":"xxxx"}}: json: unsupported type: map[interface {}]interface {}

This is with the manifest as below:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: imgproxy-service-account
  labels:
    imgproxy: "true"
    <<:
      test: test

Removing the <<: and inlining the test:test works fine. It appears as though kustomize will result in a map[interface {}]interface {} instead of a map[string]interface {} somehow. Maybe related to the yaml parser they use ?

This is with kustomize v4.5.2

@ has just updated the Configuration part of the documentation.
Please, check the difference and make the necessary changes in the Helm chart.

Just upgraded to the v0.8.0 and get the following error when setting resources.deployment.replicas.maxCount: 3:

Error validating data: [ValidationError(HorizontalPodAutoscaler.spec.metrics[1]): unknown field "containerResource" in io.k8s.api.autoscaling.v2beta2.MetricSpec, ValidationError(HorizontalPodAutoscaler.spec.metrics[1]): missing required field "type" in io.k8s.api.autoscaling.v2beta2.MetricSpec]

The development env is running on K8S 1.19.8.

I want serve image proxy to multiple host, but i can't do that. Pls support it.

@ has just updated the Configuration part of the documentation.
Please, check the difference and make the necessary changes in the Helm chart.

Is it possible to add service annotations ?

In my environment with Kubernetes 1.18 and 1.21, I have multiple ingress and corresponding certificates.

With Kubernetes 1.18, everything is working fine but with Kubernetes 1.21, ingressClassName must be set in order for TLS take to effect even with default-ssl-certificate is set in ingress-nginx configuration.

I'm not sure whether the issue happen with other configurations but I think it's better to have ingressClassName configurable.

Would it be possible to upgrade the appVersion to 2.16.0? We'd like to crop our images with percentage values, which wasn't supported until 2.16.0.

Thanks in advance!

@ has just updated the Configuration part of the documentation.
Please, check the difference and make the necessary changes in the Helm chart.

I can't run the image darthsim/imgproxy:v2.17.0 in our kubernetes cluster because the container is running as the root user.
Our cluster has a restriction that prevents running containers as root -> runAsNonRoot

Is it possible to make it so that the container can run as a non-root user?

@ has just updated the Configuration part of the documentation.
Please, check the difference and make the necessary changes in the Helm chart.

The ingress configuration uses / as the default path. The only way to adjust this is to use the features.server.pathPrefix, but changing pathPrefix will change URL handling from e.g. example.com/abc to example.com/{pathPrefix}/abc.

The problem is that AWS loadbalancer uses /* to define the wildcard path instead of /. I think the default path should be configurable. See https://github.com/imgproxy/imgproxy-helm/blob/master/imgproxy/templates/ingress.yaml#L43

@ has just updated the Configuration part of the documentation.
Please, check the difference and make the necessary changes in the Helm chart.

@ has just updated the Configuration part of the documentation.
Please, check the difference and make the necessary changes in the Helm chart.

Hi,

I've set up imgproxy with sentry, and everything's working ok. But I've set reportDownloadingErrors: false, and it doesn't do anything. These errors are still coming through to sentry.

I can see in my pod that IMGPROXY_REPORT_DOWNLOADING_ERRORS has not been set. But since the default value of that env variable is true in the server code, and it isn't being overridden, then surely that will mean the value will always be true? If we set reportDownloadingErrors: false in our config, then this should result in IMGPROXY_REPORT_DOWNLOADING_ERRORS=false to override the default value in the server, correct?

Currently the documentation in Readme.md suggests that features.urlSignature.enabled defaults to false

However, when looking at the default values.yaml it is set to true

I suggest to change the value in values.yaml to be false, since defaulting this option on does very little for security unless one also changes the key and salt.

in values.yaml the default for ttl is currently this:

    # ENV['IMGPROXY_TTL']
    # Duration in seconds sent in Expires and Cache-Control: max-age headers.
    ttl: 3600

this should be changed to:

    # ENV['IMGPROXY_TTL']
    # Duration in seconds sent in Expires and Cache-Control: max-age headers.
    ttl: "3600"

I you just change the number to something like 2419200 (=4 weeks), imgroxy will not use it and instead will continue to use the built-in default of 3600 seconds.
If you want to use a different TTL than 3600, you have to use quotes.
This took me some time to figure out.

imgproxy provides a huge number of configuration options (see https://github.com/imgproxy/imgproxy/blob/master/docs/configuration.md) which gives freedom of how to use imgproxy in your infrastructure.
The Helm chart maps those environment variables to secrets which makes sense for the sensitive information (key, salt etc.). The values.yaml provides a convenient way to configure those "features". However, it doesn't give any freedom to configure missing/new variables like IMGPROXY_LOCAL_FILESYSTEM_ROOT, which isn't part of the Helm chart by intention (see #2).

IMHO a Helm chart should provide maximum freedom and flexibility also for new features in imgproxy. ATM it only provides an opinionated set of supported configuration options.

Instead of having these if-clauses in env-secret.yaml and limit the configurations which can be set in the values.yaml it would be more flexible to just use a sequence with the actual configuration/variable name (see https://stackoverflow.com/questions/54329477/converting-a-yaml-sequence-to-a-yaml-map-in-a-helm-chart-kubernetes) like this:

features:
  - name: IMGPROXY_KEY
    value: asdf123
  - name: IMGPROXY_SALT
    value: yyy
  - name: IMGPROXY_SIGNATURE_SIZE
    value: xxx  

I see two options: Either you release a new major version of the chart and introduce a breaking change by transforming the current implementation with a key/value sequence. Or, and maybe this is a better option, you add a sequence as "features.extraConf" and append it to the env-secrect.yaml:

values.yaml:

features:
  extraConf:
    - name: IMGPROXY_LOCAL_FILESYSTEM_ROOT
      value: "/images"

env-secrect.yaml:

{{- range .Values.features.extraConf }}
  {{ .name }}:{{ .value}}
{{- end }}

Would that be an enhancement you would accept?

@dragonsmith wrote:

Old K8s API version for ingress will be unavailable soon

extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress

Here is a good example what should we do: https://github.com/prometheus-community/helm-charts/blob/main/charts/kube-prometheus-stack/templates/_helpers.tpl#L104-L113

@ has just updated the Configuration part of the documentation.
Please, check the difference and make the necessary changes in the Helm chart.

@ has just updated the Configuration part of the documentation.
Please, check the difference and make the necessary changes in the Helm chart.

@ has just updated the Configuration part of the documentation.
Please, check the difference and make the necessary changes in the Helm chart.

It would be great to have an option to add global commonLables to all resources like for example in the kube-prometheus-stack helm chart (https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack):

## Labels to apply to all resources
##
commonLabels: {}
# scmhash: abc123
# myLabel: aakkmd

This could make it a lot more flexible for several use cases.

Hello!

I am in the process of standing up imgproxy-helm. I am trying to figure out the best way to redirect http to https or just not listen on http/80. I did not see any method for doing this in the documentation. FWIW we are using AWS/EKS/ALB for this setup.

Thanks for your help,
John

Hi. How soon imgproxy v2.16 will be supported?

There is localFileSystemRoot setting, but there is no way to attach any volume to the pod. I will create a PR later for that. Any suggestions how the configuration for that should look like?

When installing/upgrading, I get this warning:

W0609 12:47:59.725527 168668 warnings.go:70] policy/v1beta1 PodDisruptionBudget is deprecated in v1.21+, unavailable in v1.25+; use policy/v1 PodDisruptionBudget

Maybe something like the apiVersion support for the Ingress template should be ported over to the PDB?

In docs described, we should use features.logging.logFormat and features.logging.logLevel, but in fact features.logging.format and features.logging.level are used.

I'm using imgproxy on GCP in a GKE cluster with workload identity enabled. Therefore, I don't need any key to authenticate.
The way it is designed here renders it required and so I have no way to not specify a key.

https://github.com/imgproxy/imgproxy-helm/blob/master/imgproxy/templates/env-secret.yaml#L330=

In fact it is really ambiguous here because the doc says it should work without:
https://docs.imgproxy.net/serving_files_from_google_cloud_storage?id=setup-credentials