Skip to content

Commit

Permalink
Add docs that describes requirements for a repo auto-update and docke…
Browse files Browse the repository at this point in the history
…r registry scanning components
  • Loading branch information
Alexander Matyushentsev authored and alexmt committed Jan 16, 2020
1 parent 21a4cdc commit aedd5f5
Show file tree
Hide file tree
Showing 3 changed files with 64 additions and 0 deletions.
1 change: 1 addition & 0 deletions .gitignore
Original file line number Diff line number Diff line change
@@ -1,2 +1,3 @@
*.swp
*~
.vscode
31 changes: 31 additions & 0 deletions specs/deployment-repo-update.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
# Deployment Repo Update Automation

## Summary

The GitOps driven continuous deployment cycle starts with a change in the Git repository that contains resource manifests. The [Flux] provides the
[Automated Image Update](https://docs.fluxcd.io/en/latest/references/automated-image-update.html) feature that continuously monitors the docker registry and automatically
updates deployment repo when a new image is released. Obviously that functionality is not available for Argo CD users.
Also cannot or don't want to use docker-registry monitoring and only need functionality related to the Git repository update.

This document is meant to collect requirements for the Git repository update functionality. As a next step, we could discuss if it is possible to implement a Golang library or
a service that can be used in combination with Argo CD and Flux.

## Requirements

### Manifests updating.

After new images are discovered the resource manifests of each workflow referencing the image have to be updated. The manifests might be stored as raw YAML files or as the templating tool package such as Kustomize or Helm. The manifest updating functionality should take new images
set as an input and update manifest files or templating tool configs to use the provided set of images.

### Commit signing

The user might want to use GPC signing for each commit in the deployment repo. The commit signing feature should allow to optionally
sign the commit with the image changes.

### Git interaction

The Git interaction feature provides the following basic functionalities:
* Clone Git repo or update the local copy of a previously cloned copy
* Configure local Git user name and email.
* Push changes back to Git remote repo.
* Rebase remote changes in case of concurrent repository update.
32 changes: 32 additions & 0 deletions specs/image-update-monitoring.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
# Docker Image Update Monitoring

## Summary

Many GitOps users would like to automate Kubernetes manifest changes in the deployment repository
(see [Deployment Repo Update Automation](./deployment-repo-update.md)). The changes might be triggered by
the CI pipeline run or a new image in the Docker registry. The [Flux] provides the docker registry monitoring as part of
[Automated Image Update](https://docs.fluxcd.io/en/latest/references/automated-image-update.html) feature but that functionality
is not available for non-Flux users and cannot be leveraged in manifests are generated by a script (e.g. jsonnet).

This document is meant to collect requirements for a component that provides docker registry monitoring functionality and
can be used by Argo CD and potentially Flux users.

## Requirements

### Configurable Event Handle

When a new docker image is discovered the component should execute a pre-configured event handler and pass the docker image name/version as a parameter. The handler should be
configured in a form of a shell script.

### Docker Registry WebHooks

Some Docker Registries send a webhook when a new image gets pushed. The component should provide a webhook handler which when invokes an event handler.

### Image Pulling

In addition to the webhook, the component should support image pulling. The pulling should detect the new images and invoke an event handler for each new image.

### Image Credentials Auto-Discovering

If a component is running inside of a Kubernetes cluster together with the deployments then it already has access to the Docker registry credentials. Auto-Discovering functionality
detect available docker registry credentials and use them to access registries instead of requiring users to configure credentials manually.

0 comments on commit aedd5f5

Please sign in to comment.