Setting up the Git repository for GitOps

To enable GitOps and be able to follow the updates of the ClusterFactory repository, you should fork the ClusterFactory repository or create a private copy, so you could use Argo CD on your own repository.

Setting up the Git repository

1. Fork the repository

Method 1: Create a public fork

Use the "Fork" button on Github and create the fork on your favorite account.

Fork button

After setting up the fork, git clone the fork. Example:
user@local:/
```
# SSH
git clone git@github.com:<your account>/ClusterFactory.git
```

Method 2: Create a private fork

Create a bare clone of the repository.

user@local:/

git clone --bare https://github.com/SquareFactory/ClusterFactory.git

Create a new private repository on your favorite Git hosting website and name it ClusterFactory.

Mirror-push your bare clone to your new ClusterFactory repository.

user@local:/
cd ClusterFactory.git
# SSH
git push --mirror git@github.com:<your account>/ClusterFactory.git

Remove the bare clone.
user@local:/ClusterFactory.git
```
cd ..
rm -rf ./ClusterFactory.git
```
You can now clone your ClusterFactory repository on your machine.
user@local:/
```
# SSH
git clone git@github.com:<your account>/ClusterFactory.git
```

2. Setup the upstream remote for git

Git is capable of managing multiple remote repositories. By default, origin is linked to the <your account>/ClusterFactory repository. To be able to fetch updates from the upstream SquareFactory/ClusterFactory repository, we need to add a remote repository that we call upstream.

Add the upstream and disable push on the remote upstream:

user@local:/ClusterFactory
git remote add upstream https://github.com/SquareFactory/ClusterFactory.git
git remote set-url --push upstream DISABLE

You can list all your remotes with git remote -v:

user@local:/ClusterFactory
git remote -v
# origin    git@github.com:<your account>/ClusterFactory.git (fetch)
# origin    git@github.com:<your account>/ClusterFactory.git (push)
# upstream  https://github.com/SquareFactory/ClusterFactory.git (fetch)
# upstream  DISABLE (push)

3. Checkout to a stable version and create a new branch

You can checkout to a stable version:

user@local:/ClusterFactory
git checkout -b configs v0.7.0
# You can delete the local main branch
git branch -D main

4. Rename the examples and commit

Copy argo.example, core.example, cfctl.yaml.example, and remove the .example:

user@local:/ClusterFactory
cp -R argo.example/ argo/
cp -R core.example/ core/
cp cfctl.yaml.example cfctl.yaml

You can track these files on Git:

user@local:/ClusterFactory
git add .
git commit -m "Initialized my config"
git push -u origin configs
# You can also delete the remote main branch

Use `git fetch` and `git merge` to merge the upstream main into the local branch

Because ClusterFactory will be updated regularly, you can fetch the updates with git fetch:

user@local:/ClusterFactory

git fetch --tags upstream

git-fetch

To merge the upstream changes, either rebase or create a merge commit.

user@local:/ClusterFactory

git merge v0.8.0

git-merge

user@local:/ClusterFactory

git push

git-push

If you wish to follow the upstream main branch:

user@local:/ClusterFactory
git merge upstream/main
git push

If everything goes well, your git graph should always look like this:

git-graph-example

Use Argo CD to pull, synchronize and deploy the manifests

If you want to deploy your applications, you should write your manifests and commit these files to your repository, like this:

./
├── argo/
├── bin/
├── core/
├── helm/
│   ├── csi-driver-cvmfs/
│   ├── cvmfs-server/
│   ├── cvmfs-service/
│   ├── ipmi-exporter/
│   ├── my-helm-application/  <----- HERE if it's a helm application
│   │   ├── templates/
│   │   ├── Chart.yaml
│   │   └── values.yaml
│   ├── openldap/
│   ├── slurm-cluster/
│   └── xcat/
├── manifests/                <----- Or HERE if it's a kustomized/vanilla Kubernetes application
│   └── my-application/       <-----
│       └── statefulset.yaml  <-----
└── ...

Argo CD is able to retrieve your repository from your Git hosting server, synchronize changes and deploy your Kubernetes manifests.

Create a local secret containing a SSH deploy key and the git url:

argo/default/secrets/my-repository-secret.yaml.local
apiVersion: v1
kind: Secret
metadata:
  name: my-repository-secret
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
type: Opaque
stringData:
  sshPrivateKey: |
    -----BEGIN RSA PRIVATE KEY-----
    -----END RSA PRIVATE KEY-----
  type: git
  url: git@github.com:<your account>/<your repo>.git

Seal it and apply it:

cfctl kubeseal
kubectl apply -f argo/default/secrets/my-repository-sealed-secret.yaml

Configure an Argo CD Application:

argo/default/apps/my-application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-application
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: git@github.com:<your account>/<your repo>.git
    # You should use your branch too.
    targetRevision: HEAD
    path: manifests/my-application
    directory:
      recurse: true

  destination:
    server: 'https://kubernetes.default.svc'
    namespace: default

  syncPolicy:
    automated:
      prune: true # Specifies if resources should be pruned during auto-syncing ( false by default ).
      selfHeal: true # Specifies if partial app sync should be executed when resources are changed only in target Kubernetes cluster and no git change detected ( false by default ).
      allowEmpty: false # Allows deleting all application resources during automatic syncing ( false by default ).
    syncOptions: []
    retry:
      limit: 5 # number of failed sync attempt retries; unlimited number of attempts if less than 0
      backoff:
        duration: 5s # the amount to back off. Default unit is seconds, but could also be a duration (e.g. "2m", "1h")
        factor: 2 # a factor to multiply the base duration after each failed retry
        maxDuration: 3m # the maximum amount of time allowed for the backoff strategy

And apply it:

kubectl apply -f argo/default/apps/my-application.yaml

Argo CD will deploy and synchroize automatically by following the HEAD commit. You can also specify the branch instead of HEAD.

Setting up the Git repository for GitOps