Continuous Deployment

After installing Kommander and configuring your project and its clusters, navigate to the Continuous Deployment (CD) tab under your Project. Here you create a GitOps source which is a source code management (SCM) repository hosting the application definition. D2iQ recommends that you create a secret first then create a GitOps source accessed by the secret.

Set up a secret for accessing GitOps

Create a secret that Kommander uses to deploy the contents of your GitOps repository:

NOTE: This dialog box creates a types.kubefed.io/v1beta1, Kind=FederatedSecret and this is not yet supported by DKP CLI. Use the GUI, as described above, to create a federated secret or create a FederatedSecret manifest and apply it to the project namespace. Learn more about FederatedSecrets.

Kommander secrets (for CD) can be configured to support any of the following three authentication methods:

HTTPS Authentication (described above)
HTTPS self-signed certificates
SSH Authentication

The following table describes the fields required for each authentication method:

HTTP Auth	HTTPS Auth (Self-signed)	SSH Auth
username	username	identity
password	password	identity.pub
	caFile	known_hosts

If you are using GitOps by using a GitHub repo as your source, you can create your secret with a personal access token. Then, in the DKP UI, in your project, create a Secret, with a key:value pair of password: <your-token-created-on-github>. If you are using a GitHub personal access token, you do not need to have a key:value pair of username: <your-github-username>.

If you are using a secret with your GitHub username and your password, you will need one secret created in the DKP UI, with key:value pairs of username: <your-github-username> and password: <your-github-password>. Note: if you have multi-factor authentication turned on in your GitHub account, this will not work.

NOTE: Using a token without a username is valid for GitHub, but other providers (such as GitLab) require both username and tokens.

IMPORTANT: If you are using a public GitHub repository, you do not need to use a secret.

Create GitOps Source

After the secret is created, you can view it in the Secrets tab. Configure the GitOps source accessed by the secret.

NOTE: If using an SSH secret, the SCM repo URL needs to be an SSH address. It does not support SCP syntax. The URL format is ssh://user@host:port/org/repository.

It takes a few moments for the GitOps Source to be reconciled and the manifests from the SCM repository at the given path to be federated to attached clusters. After the sync is complete, manifests from GitOps source are created in attached clusters.

After a GitOps Source is created, there are various commands that can be executed from the CLI to check the various stages of syncing the manifests.

On the management cluster, check your GitopsRepository to ensure that the CD manifests have been created successfully.

kubectl describe gitopsrepositories.dispatch.d2iq.io -n<PROJECT_NAMESPACE> gitopsdemo

Name:         gitopsdemo
Namespace:    <PROJECT_NAMESPACE>
...
Events:
  Type    Reason               Age    From                        Message
  ----    ------               ----   ----                        -------
  Normal  ManifestSyncSuccess  1m7s  GitopsRepositoryController  manifests synced to bootstrap repo
...

On the attached cluster, check for your Kustomization and GitRepository resources. The status field reflects the syncing of manifests:

kubectl get kustomizations.kustomize.toolkit.fluxcd.io -n<PROJECT_NAMESPACE> <GITOPS_SOURCE_NAME> -oyaml

...
status:
  conditions:
  - reason: ReconciliationSucceeded
    status: "True"
    type: Ready
    ...
...

Similarly, with GitRepository resource:

kubectl get gitrepository.source.toolkit.fluxcd.io -n<PROJECT_NAMESPACE> <GITOPS_SOURCE_NAME> -oyaml

...
status:
  conditions:
  - reason: GitOperationSucceed
    status: "True"
    type: Ready
    ...
...

If there are errors creating the manifests, those events are populated in the status field of the GitopsRepository resource on the management cluster, the GitRepository and Kustomization resources on the attached cluster(s), or both.

Suspend GitOps Source

There may be times when you need to suspend the auto-sync between the GitOps repository and the associated clusters. This live debugging may be necessary to resolve an incident in the minimum amount of time without the overhead of pull request based workflows.

To Suspend the GitOps Source from the DKP UI:

From the top menu bar, select your target workspace.
Select Projects from the sidebar menu.
Select your project from the list.
Select the Continuous Deployment (CD) tab.
Select the three dot button to the right of the desired GitOps Source.
Select Suspend to manually suspend the GitOps reconciliation.

This lets you use kubectl, helm, or another tool to resolve the issue. After the issue is resolved select Resume to sync the updated contents of the GitOps source to the associated clusters.

Similar to Suspend/Resume, you can use the Delete action to remove the GitOps source. Removing the GitOps source results in removal of all the manifests applied from the GitOps source.

You can have more than one GitOps Source in your Project to deploy manifests from various sources.

Kommander deployments are backed by FluxCD. Please refer to Flux Source Controller and Kustomize controller docs for advanced configuration and more examples.