-
Notifications
You must be signed in to change notification settings - Fork 258
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add docs that describes requirements for a repo auto-update and docke…
…r registry scanning components
- Loading branch information
Showing
3 changed files
with
64 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,2 +1,3 @@ | ||
*.swp | ||
*~ | ||
.vscode |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. |