Vaultwarden requires basically no configuration anymore. Older versions needed some environment variables for configuring the WebSocket server, but as of 1.31, WebSockets are handled by the same server as HTTP, so even that is not necessary now. The only other option that could potentially be useful is `ADMIN_TOKEN`, but it's optional. For added security, we can leave it unset, which disables the administration console; we can set it later if/when we actually need that feature. Migrating data from the old server was pretty simple. The database is pretty small, and even the attachments and site icons don't take up much space. All-in-all, there was only about 20 MB to move, so the copy only took a few seconds. Aside from moving the Vaultwarden server itself, we will also need to adjust the HAProxy configuration to proxy requests to the Kubernetes ingress controller. |
||
---|---|---|
.. | ||
applications | ||
README.md | ||
hooks.yaml | ||
ingress.yaml | ||
kustomization.yaml | ||
namespace.yaml | ||
oidc.config | ||
policy.csv |
README.md
Argo CD
Argo CD is a declarative GitOps continuous delivery tool, which allows developers to define and control deployment of Kubernetes application resources from within their existing Git workflow.
kubectl apply -k argocd
kubectl apply -f argocd/applications
Components
Argo CD consists of several components, some of which are not used:
- Application Controller
- Repository Service
- Web Server
- Notification Controller
- ApplicationSet Controller1
- Dex Server2
Applications
Applications are the core resource in Argo CD. They form a collection of resources associated with a particular application deployment. They are themselves defined as Kubernetes resources (see applications).
Git Webhook
Argo CD will automatically refresh the desired state of applications whenever a changeset is pushed to the Git repository where manifests are stored. The infra/kubernetes repository has a Webhook configured in Gitea that notifies the Argo CD server on Git push events.