How do I generate the appOfApps file?

[liyangau]

Hi,

Following the guide, it can generate applications with their YAML files successfully but I am not too sure how to generate this appOfApps application.

Do we create this file manually as below?

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: appOfApps
  namespace: argocd
spec:
  destination:
    namespace: argocd
    server: https://kubernetes.default.svc
  project: default
  source:
    path: ./manifests/dev/apps
    repoURL: [email protected]:xxx/argocd.git
    targetRevision: main

[arnarg]

Hey @liyangau! Thanks for the first question :D

Yes, so far at least, this is not generated by nixidy. The sample you provided should work as far as I can tell but you can also add the initial apps application using the Web GUI Argo CD provides.

Maybe there should be some kind of nixidy bootstrap command in the CLI that outputs this on stdout or something, it would be great to hear your opinion.

[arnarg]

I created an issue for this too. I agree that this needs to be better defined for someone who is not familiar with Argo CD and generally it would be better to guide the user through this.

See #23

[liyangau]

Thanks @arnarg for the reply.

I was reading the documentation and these two options nixidy.appOfApps.name and nixidy.appOfApps.namespace seem to suggests the appOfApps application (the entry point) could be generated automatically but I could not figure out how.

In my opinion it will be quite convenient to generate this appOfApps application to help user to bootstrap their cluster unless the user does not want to use the App of Apps model.

Additionally, a tutorial on the bootstrap process would be especially helpful for new ArgoCD users like myself. I usually use FluxCD, but nixidy has inspired me to give ArgoCD a try.

[arnarg]

I was reading the documentation and these two options nixidy.appOfApps.name and nixidy.appOfApps.namespace seem to suggests the appOfApps application (the entry point) could be generated automatically but I could not figure out how.

Those values are used in the generated applications in the app of apps folder. They can absolutely also be used to generate an initial bootstrap application.

In my opinion it will be quite convenient to generate this appOfApps application to help user to bootstrap their cluster unless the user does not want to use the App of Apps model.

I agree. I hadn't considered this before.

So I have 2 ideas:

• To add a nixidy bootstrap command that I mentioned above
  • This could be used like this: nixidy bootstrap .#dev | kubectl apply -f -
• Generate a bootstrap.yaml file in the root of the environment directory (and maybe a bootstrap.md or a README.md if not specified in extraFiles).

Whatever I'd go with I would document well of course.

Do you have an opinion on what you'd prefer? Personally option 1 sounds more reasonable to me as it's only needed once on a fresh cluster, so generally not needed longterm in an environment directory. It's however maybe a little less discoverable so needs to be well documented in the user guide.

Additionally, a tutorial on the bootstrap process would be especially helpful for new ArgoCD users like myself. I usually use FluxCD, but nixidy has inspired me to give ArgoCD a try.

I also agree that this needs to be added to the getting started guide so that you end up with a functional cluster with all the manifests synced. I however don't want to document how to install Argo CD and such that is already available in Argo CD's documentation and would just clutter ours.

Overall I think your request sounds reasonable and would be beneficial. Please let me know if you think my suggestions would be good or even if you have a better one.

Thanks :)

[liyangau]

Hi,

Do you have an opinion on what you'd prefer? Personally option 1 sounds more reasonable to me as it's only needed once on a fresh cluster, so generally not needed longterm in an environment directory. It's however maybe a little less discoverable so needs to be well documented in the user guide.

I spent some time experimenting with ArgoCD over the weekend. Initially, I thought it might be best to create the entry point application within the module so the entry points can be generates automatically with the switch sub-command and maybe even multiple entry point can be generated.

The idea was that users can define environments like this:

envs = {
  dev.modules = [ ./env/dev.nix ];
  infra.modules = [ ./env/infra.nix ];
};

Each module would have its own entry point, and an overarching all-apps application would include both the dev and infra entry points. The user would then only need to apply the all-apps application, which would follow this sync order:

All-apps → dev + infra
All infra apps sync → All dev apps sync (once infra apps are healthy)

However, I quickly ran into issues with ArgoCD’s dependency handling and application health checks. The sync wave did not work as expected in my testing.

In my case, I need the service mesh to be installed before deploying applications so that sidecars can be injected properly.

Anyway, both options—using a bootstrap sub command or a module option—should work fine. With the bootstrap approach, I’d likely run nixidy bootstrap .#dev > module/dev/dev-app-all.yaml, followed by kubectl apply -f module/dev/dev-app-all.yaml to initialise the app.

This ensures that the app can be deployed on machines without Nix installed.

I also agree that this needs to be added to the getting started guide so that you end up with a functional cluster with all the manifests synced. I however don't want to document how to install Argo CD and such that is already available in Argo CD's documentation and would just clutter ours.

I agree. The quick start tutorial shouldn’t cover ArgoCD installation. Instead, it should focus on demonstrating how to use Nixidy to build the manifests and bootstrap a cluster where ArgoCD is already installed.

[arnarg]

The idea was that users can define environments like this:

envs = {
  dev.modules = [ ./env/dev.nix ];
  infra.modules = [ ./env/infra.nix ];
};

Right.. I have seen this kind of approach a lot in the Flux ecosystem. Is infra a common base on all the clusters then? Won't that make it impossible to first roll out infra changes to dev before test and prod?

In my case, I need the service mesh to be installed before deploying applications so that sidecars can be injected properly.

In my cluster I have a similar issue where I create my k3s cluster without a CNI installed and then I have my cilium manifests generated by nixidy, run kubectl apply -f ./manifests/cilium/, run kubectl apply -f ./manifests/argocd/ and then add the apps app. I would love to be able to support some mechanism to make this handled for you somewhat in nixidy but I failed to think of how as most devops engineers have slightly different needs and approaches.

I'd love to hear ideas though, I just don't want nixidy to become too opinionated on an approach.

Anyway, both options—using a bootstrap sub command or a module option—should work fine. With the bootstrap approach, I’d likely run nixidy bootstrap .#dev > module/dev/dev-app-all.yaml, followed by kubectl apply -f module/dev/dev-app-all.yaml to initialise the app.

Ok great! I already implemented the bootstrap command on main and I'm planning to re-vamp the getting started guide soon.

Thanks!