Manage doco-cd configuration changes/image updates using doco-cd itself

[AlessandroZanatta]

Description

It's a common pattern with GitOps and CD to also manage the tool that does the CD... with the tool itself.

For example, it's common practice to manage ArgoCD with ArgoCD itself, after a first stage of bootstrapping.
This feature would allow for a more intuitive and dev-friendly way of managing doco-cd. After all, it is a container, hence it should also be managed the same way other containers are!

Use Case

I would like to ensure that every configuration change to doco-cd, as well as any update to the image tag, are versioned and controlled like any other deployed stack.

Additional Information

I have attempted to force this behavior onto doco-cd, but it does not appear to be possible at the moment.

In order to attempt this, I added the following to .doco-cd.yaml:

---
name: doco-cd
working_dir: services/doco-cd

and also gave the following labels to the doco-cd container itself:

    labels:
      cd.doco.metadata.manager: doco-cd
      cd.doco.repository.name: CapgeminiCisRedTeam/tools

These labels allow to bypass this check and trick doco-cd into (attempting to) manage itself.

However, the end result was that doco-cd was just erasing its container without recreating it. I haven't had the time to dig deeper in the code, but I assume it's due to how containers are handled (first destroyed and then recreated? Or maybe the doco-cd process is killed and the container never comes back since the code that should recreate it never runs, not sure).

Moreover, this approach could easily break due to an update on doco-cd internals.

I would gladly try to contribute to this in my free time, though I'm admittedly not very knowledgeable in Go.
Moreover, I've only skimmed the code base (and found a remarkably long function 👀), but I can give this a try if given some pointers (if this feature would be a good addition, which I'm very confident about)!

[kimdre]

I like the idea but this won't work with standalone Docker. Rolling updates can only be done with Docker Swarm.

[ronan-allen]

I like the idea but this won't work with standalone Docker. Rolling updates can only be done with Docker Swarm.

Just spitballing but I had the thought of doco-cd creating another container (let's called it doco-cd-upgrader) that will then upgrade the actual doco-cd container.

Had the idea based on doco-cd creating a service to prune nodes in swarm.

Unsure of the practical feasibility of the above but if it's a feature that desirable then that may be one way to perform it even in a standalone docker environment.

[gdm257]

I have successfully deployed self-manged doco-cd by these steps:

1. Start a temp doco-cd container
2. Let temp doco-cd deploy .doco-cd.gitops.yaml (with external secrets to define POLL_CONFIG), which starts a new long-term doco-cd
3. Let long-term doco-cd deploy .doco-cd.gitops.yaml (self-managed) and .doco-cd.yaml (other services)
4. Remove temp doco container
5. Update external secrets to control doco-cd

# Simple steps
cd services/doco-cd
vim .env
docker compose --project-name temp up -d
# wait temp doco-cd to start long-term doco-cd
docker container rm --force temp_doco-cd

.env for temp doco-cd:

POLL_CONFIG='
- url: https://github.com/user/repo.git
  target: gitops
'

.doco-cd.gitops.yaml example:

name: doco-cd
working_dir: services/doco-cd
external_secrets:
  GIT_ACCESS_TOKEN: "xxxxxxxxxxxxx"
  POLL_CONFIG: "xxxxxxxxxxxxx"
  SECRET_PROVIDER: "xxxxxxxxxxxxx"
  SECRET_PROVIDER_SITE_URL: "xxxxxxxxxxxxx"
  SECRET_PROVIDER_CLIENT_ID: "xxxxxxxxxxxxx"
  SECRET_PROVIDER_CLIENT_SECRET: "xxxxxxxxxxxxx"

Extermal secrets provide POLL_CONFIG for long-term doco-cd:

- url: https://github.com/user/repo.git
  target: gitops
- url: https://github.com/user/repo.git

It worked in my repo