Use local path instead of a repository as source

[SamDecrock]

Hi,

We love ArgoCD because it syncs our application with the manifests stored on git. This makes it super easy to upgrade our software: we update the manifest, argo removes the old deployments, statefulsets, services and whatnot, adds the new ones and we're done.

However, when we install our software on a single-node Kubernetes cluster that is not connected to the internet, we have a problem. We have to manually do kubectl apply -f manifest.yaml and check if we need to delete some deployments, statefulsets or any other Kubernetes components. As ArgoCD's source of truth needs to be on a git repo we cannot use Argo for this.

So my question is, is there an option to use a local path as the source of truth for our manifests? This way we can drop the manifest in specific folder and we're done. Or is that a bad idea and if so, how would you solve our problem?

[crenshaw-dev]

You could run a git provider in the offline cluster, but that's a bit heavy-weight.

It might also be possible to use an init container or some other mechanism to mount the manifests into the repo-server and then load them as a file:/// repository.

[SamDecrock]

Hmm, you mean start a local git repo and mount this to the arogcd pod(s) and access it through file:///. I will have to try this.

[crenshaw-dev]

Yep, something like that!

[krancour]

@SamDecrock the single node clusters you speak of that are not connected to the internet... what is the specific use case? Knowing the use case may help point to some other viable options.

[anthonyalayo]

I also tried changing something in the values file:

Yet even after a refresh and sync, I don't see the change on Argo CD's UI:

I SSHed into the repo server pod to check things out:

argocd@argocd-repo-server-667ddfc5bc-mjhlk:/tmp/local-git-repo/argo$ cat Chart.yaml | grep 6.0.1
    version: 6.0.1
argocd@argocd-repo-server-667ddfc5bc-mjhlk:/tmp/local-git-repo/argo$ cat values.dev.yaml | grep BOOP
        targetRevision: BOOP

And I do see the changes in the pod's mount. So there's some sort of disconnect somewhere.

[anthonyalayo]

@smp4 am i missing anything?

[smp4]

Hi @anthonyalayo, reading through your posts i thought perhaps although you were pushing your gitops repo changes to remote, you may not have been also pushing them to /tmp/local-git-repoon your cluster host machine, but your screenshot from your ssh session into the repo server pod seems to show it has picked up the targetRevision and version changes.

What I also notice is that your repo URL does not end in .git. In my cluster, the ArgoCD App Repo URL is file:///tmp/argo-gitops.git. This should only be a convention, but who knows.

mkdir -p /tmp/local-git-repo.git
cd /tmp/local-git-repo.git
git init --bare

Other than that, seeing as your argocd-repo-server has picked up your version and targetRevision settings I'd say the problem is no longer something to do with using a local git repo, but possibly something else.

Note also that /tmp is volatile - it is emptied by the OS upon reboot. The choice of this location was deliberate for me (I wanted a clean system after teardown and reboot), but maybe it isn't appropriate for you.

Hope something there helps.

[anthonyalayo]

Thanks a lot @smp4 ! I'll try fiddling with .git

[odelot]

Sorry for the late answer @smp4 . I followed your example, but I couldn't make it work. Just after adding the reference to the file -my-appset.yaml in the list of resources of the file #overlays/dev/kustomization I managed to get it working. Thank you for the example and I hope that sharing what I had to do can help someone who is facing the same problem that I faced.

[cloudcafetech]

seem issue is TARGET REVISION, cant put blank for file:///

• what I did

argopo1=`kubectl get pod -n argocd | grep argocd-server | awk '{print $1}' | head -1`
argopo2=`kubectl get pod -n argocd | grep argocd-server | awk '{print $1}' | tail -1`
kubectl wait pods/$argopo1 --for=condition=Ready --timeout=2m -n argocd
kubectl wait pods/$argopo2 --for=condition=Ready --timeout=2m -n argocd
kubectl exec -it $argopo1 -n argocd -- git clone https://github.com/myrepo/k8s-terraform
kubectl exec -it $argopo2 -n argocd -- git clone https://github.com/myrepo/k8s-terraform
kubectl create -f minio-app.yaml -n argocd
kubectl get apps -n argocd
NAME    SYNC STATUS   HEALTH STATUS
minio   Unknown       Healthy

• minio-app.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: minio
  namespace: argocd
spec:
  destination:
    namespace: minio-store
    server: 'https://kubernetes.default.svc'
  source:
    path: minio-store
    repoURL: 'file:///home/argocd/k8s-terraform'
    targetRevision: ''
  project: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

[anthonyalayo]

just to be clear, you don't have a working solution as well?

[ricker-flow]

I see the exact same behavior. Repository not found error when using a file: url

[raoakmal55]

Hi there,

Do we have any working solution to add a local file path instead of a remote git repo in argocd for an application, any example for that would be very helpful. Thank you

[anthonyalayo]

I recently looked at this again, and I still do not have anything working. I would ideally like a set up where I'm not continually committing things just to see their effects on a dev environment.

[sarathsprakash]

A alternative I think is to override using app sync once after the app create
argocd app sync minio --local /home/argocd/k8s-terraform/minio-store

[anthonyalayo]

I tried this, and it only kinda sorta worked. It did a one time sync update, but nothing like a complete tracking of the state of my local filesystem without commits to a repository. It also got complicated with an app of apps pattern.

[sarathsprakash]

Yes, I think its expected I don't think local is intended for a production rollout anyway. its supposed to be a brute force approach to do adhoc changes while testing or developing your applications.

[anthonyalayo]

@sarathsprakash i'm plagued by the following flow. Let's say I have some current argo state, and I just want to upgrade one thing and test if it all works. I would have no problem doing this on my local cluster. However, I need to maintain branches since I'm using helm. I know that maintaining branches (ie. a dev branch) is considered an anti pattern, but I can't figure out the best integration of helm + kustomize so that I don't need to do that.

For example, let's say I have the following boilerplate setup Chart.yaml for argo + managed apps:

apiVersion: v2
name: argocd-helm
description: Bootstrap a self managed argo cd via helm with app-of-apps pattern
type: application
version: 1.0.0
dependencies:
  - name: argo-cd
    version: 5.34.6
    repository: https://argoproj.github.io/argo-helm
  - name: argocd-apps
    version: 1.6.2
    repository: https://argoproj.github.io/argo-helm

and I have a corresponding values.yaml for this. I would like to just run Kustomize as a final patch after helm render in order to add this patch when testing locally:

argocd-apps:
  applications:
    - name: argocd
      source:
        helm:
          valueFiles:
            - values.dev.yaml

Do you know of a good template/format/etc to do that?

[smp4]

Hi @anthonyalayo, i made the base configuration of my homelab cluster available here: https://github.com/smp4/k3s-homelab-gitops

you can check there how i've implemented local repos. for an example of losing config from a helm chart then patching with kustomize, see infrastructure/cert-manager. there are some other examples in there too.

[sarathsprakash]

@anthonyalayo Perhaps a matrix generator of cluster and git (child generator) will help you here , Refer https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Generators-Matrix/#using-parameters-from-one-child-generator-in-another-child-generator