moving everything to active or retired vs incubating and graduated
All checks were successful
Reese's Arch Toolbox / build-and-push-arch-toolbox (push) Successful in 14s

This commit is contained in:
2025-04-19 18:46:40 -04:00
parent 6e393d90ee
commit ef9104c796
234 changed files with 456 additions and 244 deletions

View File

@@ -0,0 +1,2 @@
FROM nginx
COPY charts /usr/share/nginx/html

View File

@@ -0,0 +1,14 @@
apiVersion: v1
entries:
repository:
- apiVersion: v2
appVersion: 1.16.0
created: "2023-03-25T14:59:38.161362245-04:00"
description: A Helm repository chart
digest: 41013d6705233e1b686cfc9ed6a922f62c63e5ac4e8f1a7405ea1a9042d7b3ec
name: repository
type: application
urls:
- repository-0.1.0.tgz
version: 0.1.0
generated: "2023-03-25T14:59:38.160918033-04:00"

View File

@@ -0,0 +1,8 @@
version: '3'
services:
repo:
image: ducoterra/helm-repository:latest
build: .
ports:
- 8080:80

View File

@@ -0,0 +1,87 @@
# Personal Helm Repository
A helm repository is really, really simple. It's a static website that serves, at least,
a file called `index.yaml`. This file is auto-generated (see [Adding a chart](#adding-a-chart)
below) via helm commands.
Charts are added by copying their respective tgz archives into the webserver's content
directory. For example: /usr/share/nginx/html when using nginx.
Since charts are usually small you don't need a volume, you can copy the contents of your
charts directory into the webserver's docker image and serve a completely stateless repository.
You could potentially have a repository for each project or have an org-wide repository
that gets built automatically with something like gitlab/github pages.
## Gettings started
Create a folder called "charts".
Run `helm repo index charts`. An `index.yaml` will be created. It shouldn't have anything
in it.
Now you can run `podman-compose build` to create the image. This will copy the charts
folder into an nginx container. `podman-compose push` will upload the container to the
registry.
## Deploying the Repository
We can use the local chart (for now) to deploy the chart image.
```bash
helm upgrade --install \
chart-repository \
./repository \
--namespace chart-repository \
--create-namespace
```
## Using the Repository
You can add the repository to your local helm client like any other:
```bash
helm repo add reeseapps https://charts.reeseapps.com
```
You can view the existing charts with
```bash
helm search repo reeseapps
```
Though nothing will show up right now...
## Adding a chart
We can add a chart by copying its .tgz package into `charts/`. For example:
```bash
helm package ./repository
mv repository-0.1.0.tgz charts/
```
Now recreate the index with
```bash
helm repo index charts
```
You should see a new entry in the index.yaml.
## Updating the image
Now that you have something in your index, we can update the image by following the
same process we used to deploy it:
```bash
podman-compose build
podman-compose push
helm upgrade --install \
chart-repository \
./repository \
--namespace chart-repository \
--create-namespace
```
Now run `helm repo update` and `helm search repo reeseapps`. You should see the new
chart added.

View File

@@ -0,0 +1,23 @@
# Patterns to ignore when building packages.
# This supports shell glob matching, relative path matching, and
# negation (prefixed with !). Only one pattern per line.
.DS_Store
# Common VCS dirs
.git/
.gitignore
.bzr/
.bzrignore
.hg/
.hgignore
.svn/
# Common backup files
*.swp
*.bak
*.tmp
*.orig
*~
# Various IDEs
.project
.idea/
*.tmproj
.vscode/

View File

@@ -0,0 +1,24 @@
apiVersion: v2
name: repository
description: A Helm repository chart
# A chart can be either an 'application' or a 'library' chart.
#
# Application charts are a collection of templates that can be packaged into versioned archives
# to be deployed.
#
# Library charts provide useful utilities or functions for the chart developer. They're included as
# a dependency of application charts to inject those utilities and functions into the rendering
# pipeline. Library charts do not define any templates and therefore cannot be deployed.
type: application
# This is the chart version. This version number should be incremented each time you make changes
# to the chart and its templates, including the app version.
# Versions are expected to follow Semantic Versioning (https://semver.org/)
version: 0.1.0
# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application. Versions are not expected to
# follow Semantic Versioning. They should reflect the version the application is using.
# It is recommended to use it with quotes.
appVersion: "1.16.0"

View File

@@ -0,0 +1,73 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}
spec:
selector:
matchLabels:
app.kubernetes.io/name: {{ .Release.Name }}
strategy:
type: Recreate
template:
metadata:
labels:
app.kubernetes.io/name: {{ .Release.Name }}
spec:
containers:
- name: nginx
image: ducoterra/helm-repository:latest
imagePullPolicy: Always
ports:
- containerPort: 80
name: http
resources:
requests:
memory: "1Gi"
cpu: "1m"
limits:
memory: "1Gi"
cpu: "1"
---
apiVersion: v1
kind: Service
metadata:
name: {{ .Release.Name }}
spec:
type: ClusterIP
selector:
app.kubernetes.io/name: {{ .Release.Name }}
ports:
- name: http
protocol: TCP
port: 80
targetPort: http
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: {{ .Release.Name }}
annotations:
cert-manager.io/cluster-issuer: letsencrypt
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/proxy-body-size: "0"
nginx.org/client-max-body-size: "0"
spec:
rules:
- host: {{ .Values.domain }}
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: {{ .Release.Name }}
port:
name: http
tls:
- hosts:
- {{ .Values.domain }}
secretName: {{ .Release.Name }}-tls-cert

View File

@@ -0,0 +1 @@
domain: charts.reeseapps.com