Files
athens-proxy-charts/README.md
Markus Pesch fbd846784c
Some checks failed
Helm / helm-lint (push) Successful in 6s
Helm / helm-unittest (push) Successful in 7s
Markdown linter / markdown-link-checker (push) Successful in 11s
Generate README / generate-parameters (push) Failing after 28s
Markdown linter / markdown-lint (push) Successful in 17s
fix(networkPolicy): use single network policy
2025-10-12 17:21:05 +02:00

5.8 KiB

athens-proxy-charts

Artifact Hub

Note

This is not the official helm chart of Athens Go Proxy. If you are looking for the official helm chart, checkout the GitHub project gomods/athens-charts.

This helm chart enables the deployment of Athens Go Proxy, a module datastore and proxy for Golang.

The helm chart supports the individual configuration of additional containers/initContainers, mounting of volumes, defining additional environment variables and much more.

Chapter configuration and installation describes the basics how to configure helm and use it to deploy the exporter. It also contains further configuration examples.

Furthermore, this helm chart contains unit tests to detect regressions and stabilize the deployment. Additionally, this helm chart is tested for deployment scenarios with ArgoCD, but please keep in mind, that this chart supports the Automatically Roll Deployment concept of Helm, which can trigger unexpected rolling releases. Further configuration instructions are described in a separate chapter.

Helm: configuration and installation

  1. A helm chart repository must be configured, to pull the helm charts from.
  2. All available parameters are documented in detail below. The parameters can be defined via the helm --set flag or directly as part of a values.yaml file. The following example defines the repository and use the --set flag for a basic deployment.
helm repo add volker.raschek https://charts.cryptic.systems/volker.raschek
helm repo update
helm install athens-proxy volker.raschek/athens-proxy

Instead of passing all parameters via the set flag, it is also possible to define them as part of the values.yaml. The following command downloads the values.yaml for a specific version of this chart. Please keep in mind, that the version of the chart must be in sync with the values.yaml. Newer minor versions can have new features. New major versions can break something!

CHART_VERSION=0.3.0
helm show values volker.raschek/athens-proxy --version "${CHART_VERSION}" > values.yaml

A complete list of available helm chart versions can be displayed via the following command:

helm search repo reposilite --versions

The helm chart also contains a persistent volume claim definition. It persistent volume claim is not enabled by default. Use the --set argument to persist your data.

CHART_VERSION=0.3.0
helm install --version "${CHART_VERSION}" athens-proxy volker.raschek/athens-proxy \
  persistence.enabled=true

Examples

The following examples serve as individual configurations and as inspiration for how deployment problems can be solved.

Network policies

Network policies can only take effect, when the used CNI plugin support network policies. The chart supports no custom network policy implementation of CNI plugins. It's support only the official API resource of networking.k8s.io/v1.

The example below is an excerpt of the values.yaml file. The network policy contains ingress rules to allow incoming traffic from an ingress controller. Additionally two egress rules are defined. The first one to allow the application outgoing access to the internal running DNS server core-dns. The second rule to be able to access the Apache Maven Central repository via HTTPS.

Important

Please keep in mind, that the namespace and pod selector labels can be different from environment to environment. For this reason, there is are not default network policy rules defined.

networkPolicies:
  enabled: true
  annotations: {}
  labels: {}
  policyTypes:
  - Egress
  - Ingress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - port: 53
      protocol: TCP
    - port: 53
      protocol: UDP
  - ports:
    - port: 443
      protocol: TCP

  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: ingress-nginx
      podSelector:
        matchLabels:
          app.kubernetes.io/name: ingress-nginx
    ports:
    - port: http
      protocol: TCP

ArgoCD

Daily execution of rolling updates

The behavior whereby ArgoCD triggers a rolling update even though nothing appears to have changed often occurs in connection with the helm concept checksum/secret, checksum/configmap or more generally, Automatically Roll Deployments.

The problem with combining this concept with ArgoCD is that ArgoCD re-renders the Helm chart every time. Even if the content of the config map or secret has not changed, there may be minimal differences (e.g., whitespace, chart version, Helm render order, different timestamps).

This changes the SHA256 hash, Argo sees a drift and trigger a rolling update of the deployment. Among other things, this can lead to unnecessary notifications from ArgoCD.

To avoid this, the annotation with the shasum must be ignored. Below is a diff that adds the Application to ignore all annotations with the prefix checksum.

  apiVersion: argoproj.io/v1alpha1
  kind: Application
  spec:
+   ignoreDifferences:
+   - group: apps/v1
+     kind: Deployment
+     jqPathExpressions:
+     - '.spec.template.metadata.annotations | with_entries(select(.key | startswith("checksum")))'

Parameters