argoproj-labs / argocd-image-updater Goto Github PK
View Code? Open in Web Editor NEWAutomatic container image update for Argo CD
Home Page: https://argocd-image-updater.readthedocs.io/en/stable/
License: Apache License 2.0
Automatic container image update for Argo CD
Home Page: https://argocd-image-updater.readthedocs.io/en/stable/
License: Apache License 2.0
Describe the bug
The write-back feature works only if the branch is explicitly specified in application source revision. Otherwise it tries to commit to HEAD which does not work.
To Reproduce
Configure writeback for an Argo CD app with empty targetRevision
. See error in image updater logs
Expected behavior
Image updater should detect default branch of origin and use it
Is your feature request related to a problem? Please describe.
First of all, this is an excellent addition to Argo and I think it should definitely be pulled in to the main project. This is an extremely critical feature to a GitOps flow imo.
Basically, the install process right now is cumbersome and hard to fully automate.
Current process:
argo-cd
HelmRelease for image-updater
(not a big deal)Describe the solution you'd like
A helm chart would be a great start. I think a lot of this, if not all, could be automated with helm hooks or templating. Not completely sure about the user token though. Happy to contribute one if it makes sense.
Describe alternatives you've considered
An alternative would be to fully integrate this component into Argo so no end-user configuration is required.
Additional context
N/A
Describe the bug
Per the docs, the correct way to use argocd-image-updater with Kustomize is to use the image name (e.g. argoproj/argocd
) as an alias. However, Kubernetes only allows one slash in an annotation key, so I'm unable to use the alias for other argocd-image-updater options.
To Reproduce
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
images:
- name: hjacobs/kube-resource-report
namespace: kube-resource-report
resources:
- github.com/hjacobs/kube-resource-report/deploy?ref=20.7.3
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
annotations:
argocd-image-updater.argoproj.io/image-list: hjacobs/kube-resource-report=<container_repo_url>/kube-resource-report
argocd-image-updater.argoproj.io/hjacobs/kube-resource-report.update-strategy: latest
finalizers:
- resources-finalizer.argocd.argoproj.io
name: kube-resource-report
namespace: argocd
spec:
destination:
namespace: kube-resource-report
server: https://kubernetes.default.svc
project: cluster-services
source:
path: kube-resource-report/
repoURL: <config_repo_url>
targetRevision: main
syncPolicy:
automated:
prune: true
syncOptions:
- CreateNamespace=true
Expected behavior
Creation of an Argo CD Application that continuously deploys the latest version of the <container_repo_url>/kube-resource-report
container image.
Version
0.7.0
Logs
error="Application.argoproj.io \"cluster-services-krr-bdatasf-npd-us-east4-ng\" is invalid: metadata.annotations: Invalid value: \"argocd-image-updater.argoproj.io/hjacobs/kube-resource-report.update-strategy\": a qualified name must consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyName', or 'my.name', or '123-abc', regex used for validation is '([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9]') with an optional DNS subdomain prefix and '/' (e.g. 'example.com/MyName')"
2020-10-01T20:36:15.016Z ERROR controller-runtime.controller Reconciler error {"controller": "applicationset", "name": "cluster-services-kube-resource-report", "namespace": "argocd", "error": "Application.argoproj.io \"cluster-services-krr-bdatasf-npd-us-east4-ng\" is invalid: metadata.annotations: Invalid value: \"argocd-image-updater.argoproj.io/hjacobs/kube-resource-report.update-strategy\": a qualified name must consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyName', or 'my.name', or '123-abc', regex used for validation is '([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9]') with an optional DNS subdomain prefix and '/' (e.g. 'example.com/MyName')"}
Is your feature request related to a problem? Please describe.
Currently, Docker images for argocd-image-updater
are only built & published for amd64 architecture. People might want to run on arm64 architectures.
Describe the solution you'd like
We should build & provide official Docker images for arm64 architecture.
Describe the bug
I want to use the new Github Container Registry ghcr.io but I get a strange error message "Could not get tags from registry: unexpected manifest schema was received from registry"
To Reproduce
My config map contains:
registries.conf: |
registries:
- name: Github Container Registry
api_url: https://ghcr.io
ping: no
prefix: ghcr.io
credentials: pullsecret:argocd-image-updater/regcred
Expected behavior
ghcr.io should be supported.
Additional context
Version
v0.6.1
Logs
time="2020-09-24T21:00:36Z" level=info msg="argocd-image-updater v0.6.1 starting [loglevel:INFO, interval:2m0s, healthport:8080]"
time="2020-09-24T21:00:36Z" level=info msg="Loaded 1 registry configurations from /app/config/registries.conf"
time="2020-09-24T21:00:36Z" level=info msg="ArgoCD configuration: [server=argocd-server.argocd, auth_token=true, insecure=false, grpc_web=false, plaintext=true]"
time="2020-09-24T21:00:36Z" level=info msg="Starting health probe server TCP port=8080"
time="2020-09-24T21:00:36Z" level=info msg="Warming up image cache"
time="2020-09-24T21:00:37Z" level=error msg="Could not get tags from registry: unexpected manifest schema was received from registry: application/vnd.docker.distribution.manifest.v2+json (registry may not support the manifest type(s) you want: [application/vnd.docker.distribution.manifest.v1+prettyjws application/vnd.docker.distribution.manifest.v1+json])" alias=techwiki application=techwiki image_name=windsource/techwiki image_tag=latest registry=ghcr.io
time="2020-09-24T21:00:37Z" level=info msg="Finished cache warm-up, pre-loaded 0 meta data entries from 5 registries"
time="2020-09-24T21:00:37Z" level=info msg="Starting image update cycle, considering 1 annotated application(s) for update"
time="2020-09-24T21:00:38Z" level=error msg="Could not get tags from registry: unexpected manifest schema was received from registry: application/vnd.docker.distribution.manifest.v2+json (registry may not support the manifest type(s) you want: [application/vnd.docker.distribution.manifest.v1+prettyjws application/vnd.docker.distribution.manifest.v1+json])" alias=techwiki application=techwiki image_name=windsource/techwiki image_tag=latest registry=ghcr.io
time="2020-09-24T21:00:38Z" level=info msg="Processing results: applications=1 images_considered=1 images_skipped=0 images_updated=0 errors=1"
Hi,
I use Google Container Registry for hosting my docker images. When I tag my docker image with SHA1 tag and latest tag, argocd-image-updater
found two tag for latest
strategy image.
So it first updates the pod image with the tag SHA1
.... then it updates with the latest
tag...
This operation is executed in a loop
To Reproduce
Steps to reproduce the behavior:
# Build with two tag
docker build -t eu.gcr.io/<gcp-project-id>/<image-name>:07bfd2596 -t eu.gcr.io/<gcp-project-id>/<image-name>:latest .
# Push image with two tag
docker push eu.gcr.io/<gcp-project-id>/<image-name>:07bfd2596
docker push eu.gcr.io/<gcp-project-id>/<image-name>:latest
Application YAM
apiVersion: argoproj.io/v1alpha1
...
annotations:
argocd-image-updater.argoproj.io/image-list: my_alias=eu.gcr.io/<gcp-project-id>/<image-name>
argocd-image-updater.argoproj.io/my_alias.update-strategy: latest
....
Expected behavior
I think argocd-image-updater should be based on image digest
for determine the really latest image.
Version
argocd-image-updater:0.8
Workaround
I use ignore_tags
for explicitly ignoring latest tag
apiVersion: argoproj.io/v1alpha1
...
annotations:
argocd-image-updater.argoproj.io/image-list: my_alias=eu.gcr.io/<gcp-project-id>/<image-name>
argocd-image-updater.argoproj.io/my_alias.update-strategy: latest
argocd-image-updater.argoproj.io/my_alias.ignore-tags: latest
....
Logs
time="2021-01-27T16:51:24Z" level=debug msg="Cache hit for eu.gcr.io/<gcp-project-id>/<image-name>:07bfd2596"
time="2021-01-27T16:51:24Z" level=debug msg="Cache hit for eu.gcr.io/<gcp-project-id>/<image-name>:latest"
time="2021-01-27T16:51:24Z" level=debug msg="found 2 from 2 tags eligible for consideration" image="eu.gcr.io/<gcp-project-id>/<image-name>:07bfd2596"
Describe the bug
I followed the instructions, but argo image updater does not work.
To Reproduce
Steps to reproduce the behavior:
I have annotated the application as desired as below:
argocd-image-updater.argoproj.io/myimage.helm.image-name: nitinkansal/argo-workflow
argocd-image-updater.argoproj.io/myimage.update-strategy: latest
Expected behavior
A clear and concise description of what you expected to happen.
It should search for the latest and deploy the same.
Additional context
Add any other context about the problem here.
Version
Please tell us about the version you encountered the issue with
argocd-image-updater: v99.9.9+457b52f
Logs
Please paste any relevant logs here
time="2021-03-09T15:15:50Z" level=info msg="argocd-image-updater v99.9.9+457b52f starting [loglevel:DEBUG, interval:2m0s, healthport:8080]"
time="2021-03-09T15:15:50Z" level=debug msg="rate limit for https://registry-1.docker.io is 2147483647"
time="2021-03-09T15:15:50Z" level=info msg="Loaded 1 registry configurations from /app/config/registries.conf"
time="2021-03-09T15:15:50Z" level=debug msg="Creating in-cluster Kubernetes client"
time="2021-03-09T15:15:50Z" level=debug msg="Using ArgoCD API credentials from environment ARGOCD_TOKEN"
time="2021-03-09T15:15:50Z" level=info msg="ArgoCD configuration: [apiKind=kubernetes, server=<LoadBalancer_IP>, auth_token=true, insecure=true, grpc_web=false, plaintext=true]"
time="2021-03-09T15:15:50Z" level=info msg="Starting health probe server TCP port=8080"
time="2021-03-09T15:15:50Z" level=info msg="Starting metrics server on TCP port=8081"
time="2021-03-09T15:15:50Z" level=info msg="Warming up image cache"
time="2021-03-09T15:15:50Z" level=info msg="Finished cache warm-up, pre-loaded 0 meta data entries from 5 registries"
time="2021-03-09T15:15:50Z" level=info msg="Starting image update cycle, considering 0 annotated application(s) for update"
time="2021-03-09T15:15:50Z" level=info msg="Processing results: applications=0 images_considered=0 images_skipped=0 images_updated=0 errors=0"
time="2021-03-09T15:17:50Z" level=info msg="Starting image update cycle, considering 0 annotated application(s) for update"
time="2021-03-09T15:17:50Z" level=info msg="Processing results: applications=0 images_considered=0 images_skipped=0 images_updated=0 errors=0"
Argo CD Image Updater should export some metrics about how it behaves.
Items to be included in the first throw:
Is your feature request related to a problem? Please describe.
When connecting to a custom or self-hosted registry, the user should have the option to configure skipping TLS verification for this connection.
Describe the solution you'd like
A new option for the registry configuration that skips TLS verification, i.e. insecure: <true|false>
Is your feature request related to a problem? Please describe.
Currently, image pull secrets can only be specified on a per-registry basis. That means you'd need one credential that has access to all images from this registry, which might not be possible in some scenarios.
Describe the solution you'd like
It should be possible to define Image pull secrets on a per image (or per repository) basis, using an annotation on the application resource. Depending on further design decisions (like, access to remote clusters), it could also be viable to use the imagePullSecret
property of existing workloads to figure out what pull secret to use.
Is your feature request related to a problem? Please describe.
Currently, applications are checked sequentially for whether there are images to be updated. This can take some serious time, if there are more than a couple of applications and images involved in the process.
Describe the solution you'd like
Applications should be checked & updated concurrently, up to a configurable number of maximum parallelism. This will speed up the process.
I can't figure it out the reason of this error .
Steps I followed:
1.- export AWS_ECR_PULLSECRET="AWS:eyJwYXlsb2FkIjoiKzkzVWR0blloSW5zdWFrS0I3UXFXcFV6UDU2eDJJem9HaVh0eWN0UWl1YzZwMnQ2OWJvaWJSM3dFMasdpU"
2.- argocd-image-updater test XXXXXXXX.dkr.ecr.us-east-1.amazonaws.com/k8s/ingress-nginx --update-strategy latest --credentials env:AWS_ECR_PULLSECRET
Result:
INFO[0000] getting image image_name=k8s/ingress-nginx registry=XXXXX.dkr.ecr.us-east-1.amazonaws.com
FATA[0000] could not get registry endpoint: no registry with prefix 'XXXXXXXXX.dkr.ecr.us-east-1.amazonaws.com' configured
any ideas about how to fix it ?
thanks
Is your feature request related to a problem? Please describe.
Currently, to change the log level of argocd-image-updater, it is necessary to modify the deployment spec. This is unnecessarily complicated and should be simplified.
Describe the solution you'd like
It should be possible to set the log level from an environment variable, and use an environment reference to the argocd-image-updater-config config map to actually set the level, so users can easily change the log level without being forced to edit any deployment specs.
Describe the bug
When connecting to the registry the argo-image-updater is not authenticating against the server for the access token. Therefore when getting the new image the sever thinks the request is unauthorized and therefore cannot update the images.
Version
Image: argoprojlabs/argocd-image-updater:latest
Logs
level=error msg="Could not get tags from registry: Get "https://<private_registry>/v2/library/<image_name>/tags/list": http: non-successful response (status=401 body="{\"errors\":[{\"code\":\"UNAUTHORIZED\",\"message\":\"authentication required\",\"detail\":[{\"Type\":\"repository\",\"Class\":\"\",\"Name\":\"library/<image_name>\",\"Action\":\"pull\"}]}]}\n")" alias=backend application=<argo_app>image_name=<image_name> image_tag=<image_tag> registry=<private_registry>
time="2020-09-22T18:51:20Z" level=info msg="Processing results: applications=1 images_considered=1 images_skipped=0 images_updated=0 errors=1"
Has anyone experience this with the image updater ? This was initially working fine, I've recreated it a couple of time but the same issue persists.
time="2021-02-22T23:52:33Z" level=info msg="argocd-image-updater v99.9.9+457b52f starting [loglevel:DEBUG, interval:2m0s, healthport:8080]"
time="2021-02-22T23:52:33Z" level=debug msg="rate limit for https://90152327234848.dkr.ecr.us-east-1.amazonaws.com is 2147483647"
time="2021-02-22T23:52:33Z" level=info msg="Loaded 1 registry configurations from /app/config/registries.conf"
time="2021-02-22T23:52:33Z" level=debug msg="Creating in-cluster Kubernetes client"
time="2021-02-22T23:52:33Z" level=debug msg="Using ArgoCD API credentials from environment ARGOCD_TOKEN"
time="2021-02-22T23:52:33Z" level=info msg="ArgoCD configuration: [apiKind=kubernetes, server=argocd-server.argocd.svc.cluster.local, auth_token=true, insecure=true, grpc_web=true, plaintext=true]"
time="2021-02-22T23:52:33Z" level=info msg="Starting health probe server TCP port=8080"
time="2021-02-22T23:52:33Z" level=info msg="Starting metrics server on TCP port=8081"
time="2021-02-22T23:52:33Z" level=info msg="Warming up image cache"
time="2021-02-22T23:52:33Z" level=info msg="Finished cache warm-up, pre-loaded 0 meta data entries from 6 registries"
time="2021-02-22T23:52:33Z" level=info msg="Starting image update cycle, considering 0 annotated application(s) for update"
time="2021-02-22T23:52:33Z" level=info msg="Processing results: applications=0 images_considered=0 images_skipped=0 images_updated=0 errors=0"
time="2021-02-22T23:54:33Z" level=info msg="Starting image update cycle, considering 0 annotated application(s) for update"
time="2021-02-22T23:54:33Z" level=info msg="Processing results: applications=0 images_considered=0 images_skipped=0 images_updated=0 errors=0"
time="2021-02-22T23:56:33Z" level=info msg="Starting image update cycle, considering 0 annotated application(s) for update"
time="2021-02-22T23:56:33Z" level=info msg="Processing results: applications=0 images_considered=0 images_skipped=0 images_updated=0 errors=0"
time="2021-02-22T23:58:33Z" level=info msg="Starting image update cycle, considering 0 annotated application(s) for update"
Is your feature request related to a problem? Please describe.
Currently, the image updater retrieves a list of applications using Argo CD API. That requires the creation of an Argo CD token and connection options (such as grpc-web, insecure etc).
We might simplify the initial configuration if the updater is running in the same namespace as Argo CD. In this case list of applications can be extracted using Kubernetes client.
Describe the solution you'd like
Add --applications-source
flag that takes two parameters: argocd
, namespace
. If namespace
is specified then the updater should read applications from the current namespace.
Additional context
I think this might improve adoption significantly since this way we support no configuration installation. The user just needs to run kubectl apply -n argocd -f ...
(or add one more remote base to kustomization file) and the updater should work with public image registries out of the box.
It is still good to support connecting using argocd API. Docker registry might be not available from Argo CD namespace or updater cannot be installed into the same namespace for security reasons.
time="2021-02-25T22:01:22Z" level=debug msg="Using version constraint 'latest' when looking for a new tag" alias=msa_msa-ui application=xxxxxxxxxxxxxxxx image_tag="" registry=XXXXXXXXXX.dkr.ecr.us-east-1.amazonaws.com
time="2021-02-25T22:01:23Z" level=debug msg="found 1 from 1 tags eligible for consideration" image=XXXXXXX.dkr.ecr.us-east-1.amazonaws.com/xxx/xxx
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x18d7769]
goroutine 55 [running]:
github.com/argoproj-labs/argocd-image-updater/pkg/argocd.UpdateApplication(0x1db6178, 0x1fb4f60, 0xc00046a5c0, 0xc0004146d0, 0xc000427000, 0x1fcd101, 0x0, 0x0, 0x0, 0x0, ...)
/src/argocd-image-updater/pkg/argocd/update.go:137 +0xb09
main.runImageUpdater.func1(0xc00011c870, 0xc000418c40, 0xc0003f0590, 0xc00034d9e0, 0xc000515101, 0xc0003f0594, 0xc000500270, 0xb, 0x0, 0x0, ...)
/src/argocd-image-updater/cmd/main.go:132 +0x18f
created by main.runImageUpdater
/src/argocd-image-updater/cmd/main.go:129 +0x8f6
Is your feature request related to a problem? Please describe.
Argo CD Image Updater will consider all applications with appropriate annotations for update during processing. This might sometimes not be what the user want, especially during testing.
Describe the solution you'd like
We need a way to specify a pattern on the application name (or associated project) that has to match in order for Argo CD Image Updater to process a given application. This would be most appropriate on the command line, i.e. --applications app1,app2,...
, possibly also in the project/application
notation, with wild card support.
Is your feature request related to a problem? Please describe.
Currently, the only way to filter tags is to provide a tag-match
annotation, which lets you define a pattern that has to match a tag's name in order for it to be considered. In some cases, it would be much better to invert the matcher logic and to ignore a list of tags.
Describe the solution you'd like
A new annotation containing a list of tags that should be ignored, even if matched by tag-match
patterns. This could be for example argocd-image-updater.argoproj.io/<image_name>.tag-ignore: tag1, tag2, tag3
- maybe even using glob patterns (but not regexps).
Is your feature request related to a problem? Please describe.
We currently publish binaries via GitHub release page for linux/amd64 architectures.
Describe the solution you'd like
Additional binaries for other architectures - linux/arm64 and darwin/amd64 - should be build & published via the releases page, so that people on that architectures can benefit from features of argocd-image-updater test
command.
Is your feature request related to a problem? Please describe.
People are struggling with some of the more advanced configuration. This creates frustration and hinders adoptions.
Describe the solution you'd like
We should provide more and better explained examples in the docs, such as:
Above list will grow. Please keep adding topics to this issue in the comments.
Describe the bug
Currently built argoprojlabs/argocd-image-updater
images lack SSH client resulting in errors when trying to use git write back feature with SSH git repositories.
To Reproduce
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: some-app
namespace: argocd
finalizers:
- resources-finalizer.argocd.argoproj.io
annotations:
argocd-image-updater.argoproj.io/image-list: image=[...]
argocd-image-updater.argoproj.io/write-back-method: git
argocd-image-updater.argoproj.io/image.update-strategy: latest
argocd-image-updater.argoproj.io/image.ignore-tags: latest
spec:
destination:
namespace: some-ns
server: https://kubernetes.default.svc
project: default
source:
path: some-path
repoURL: [email protected]:repopath.git
targetRevision: HEAD
Expected behavior
Additional context
FROM argoprojlabs/argocd-image-updater@sha256:a7f435f888d2f98f0bd477a36f3d4903d92755ee347365d33e414ee37c34ff26
USER 0
RUN apk update && apk add openssh-client && adduser --home "/app" --disabled-password --uid 1000 argocd
USER 1000
Above changes in addition to mounting ssh_known_hosts
file to /app/config/ssh
directory (probably needs to be documented) fix the issue.
Version
master - commit 457b52f
Describe the bug
As described in #75, the image updater will perform one application update call for the same application if multiple images are specified for update. This leads to potentially multiple syncs in Argo CD, if auto sync is enabled.
To Reproduce
Specify multiple images for update for an application that has auto sync enabled, and see that the application gets synced more than one time if more than one image has update candidates.
Expected behavior
The application should only sync once, when all image updates have been processed.
Describe the bug
I was configuring annotations for a helm app in Argo (via the argo-cd helm chart values) and forgot to specify the helm image tag/name paths, so it populated image.tag
and image.name
instead of my.custom.path
.
I added the correct name/tag paths for the images but image.name
and image.tag
parameter overrides still exist in the rendered application manifest.
To Reproduce
Steps to reproduce the behavior:
Add the following annotations to the Application and let the controller update it:
argocd-image-updater.argoproj.io/image-list: backend=some.repo/backend frontend=some.repo/frontend
argocd-image-updater.argoproj.io/backend.update-strategy: latest
Now go back to the Application and update the annotations to use the correct helm paths:
argocd-image-updater.argoproj.io/backend.helm.image-name: backend.image.repository
argocd-image-updater.argoproj.io/backend.helm.image-tag: backend.image.tag
argocd-image-updater.argoproj.io/backend.allow-tags: regexp:^dev-.*$
My application manifest still shows both parameter overrides:
helm:
parameters:
- name: image.name
value: some.repo/backend
forceString: true
- name: image.tag
value: dev-94fc3a6c73367f950935ac0e872e2d31de02f110
forceString: true
- name: backend.image.repository
value: some.repo/backend
forceString: true
- name: backend.image.tag
value: dev-94fc3a6c73367f950935ac0e872e2d31de02f110
forceString: true
Expected behavior
I would expect to only see:
helm:
parameters:
- name: backend.image.repository
value: some.repo/backend
forceString: true
- name: backend.image.tag
value: dev-94fc3a6c73367f950935ac0e872e2d31de02f110
forceString: true
Version
v0.8.0+961de70
Describe the bug
The a-i-u does not seem to pick up the registry configuration I am providing. There are no logs to this effect at all.
To Reproduce
Configmap argocd-image-updater-config with
data:
argocd.grpc_web: "false"
argocd.insecure: "true"
argocd.loglevel: debug
argocd.plaintext: "false"
argocd.server_addr: argocd-server.argocd
registries.conf: |
registries:
- api_url: https://example.com/prefix
ping: false
credentials: something
prefix: xxxx
Expected behavior
According to the relevant code (https://github.com/argoproj-labs/argocd-image-updater/blob/master/cmd/main.go#L174) I would expect a log line about the registries configuration, either a failure or a success report. But apparently cfg.RegistriesConf != ""
(L184) is evaluating to false.
Additional context
The registry configuration is correctly mounted in the container
cat app/config/registries.conf
registries:
- api_url: https://example.com/prefix
ping: false
credentials: something
prefix: xxxx
Version
v0.4.0-master
Logs
Startup logs:
time="2020-08-12T12:49:00Z" level=info msg="argocd-image-updater v0.4.0-master starting [loglevel:INFO, interval:2m0s, healthport:8080]"
time="2020-08-12T12:49:00Z" level=info msg="ArgoCD configuration: [server=argocd-server.argocd, auth_token=true, insecure=true, grpc_web=false, plaintext=false]"
time="2020-08-12T12:49:00Z" level=info msg="Starting health probe server TCP port=8080"
[EOF]
Is your feature request related to a problem? Please describe.
Some registries - such as quay.io - impose a rate limit on API requests. If a repository contains a large number of tags, the image updater may easily trigger these limits just by performing paginated requests to list the available tags. This can ultimately lead to the client IP address being blacklisted from further API access.
Describe the solution you'd like
We need a per-registry configuration for obeying rate limits imposed by the specific registry, so that we won't trigger any of these limits. This limit must be applied while listing paginated tags as well as fetching tag meta-data.
error while communicating with ArgoCD" argocd_server="server IP" grpc_web=true grpc_webroot= insecure=false
"Error: rpc error: code = Unknown desc = Post "https://ServerIp/application.ApplicationService/List\": x509: cannot validate certificate for ServerIp because it doesn't contain any IP SANs"
Though I have mentioned insecure=false, why certs are getting checked?
Any help would be highly appreciated.
Describe the bug
When specifying multiple images to update via the annotation with two of those images as the same docker image but for different containers in your k8s deployment. Image Updater seems to update only one instance of the image.
It does not seem to update the second alias.
To Reproduce
Using this feature here, create an application with two image to update.
Here is my example from our own Django helm chart:
argocd-image-updater.argoproj.io/image-list: asfalia=gcr.io/sopost-k8s/asfalia:~v0.1.0-0, celery=gcr.io/sopost-k8s/asfalia:~v0.1.0-0
argocd-image-updater.argoproj.io/asfalia.update-strategy: latest
argocd-image-updater.argoproj.io/asfalia.helm.image-name: image.repository
argocd-image-updater.argoproj.io/asfalia.helm.image-tag: image.tag
argocd-image-updater.argoproj.io/celery.update-strategy: latest
argocd-image-updater.argoproj.io/celery.helm.image-name: celery.image.repository
argocd-image-updater.argoproj.io/celery.helm.image-tag: celery.image.tag
What i find is the container (aso alias) asfalia
does get updated. But the celery
container / alias does not.
Here are my helm values input for reference:
image:
repository: gcr.io/sopost-k8s/asfalia
tag: ""
pullPolicy: Always
celery:
# When enabled, ensure all values are as expected
enabled: false
image:
repository: gcr.io/sopost-k8s/asfalia
tag: ""
pullPolicy: IfNotPresent
Expected behavior
Both containers should be updated at the same time when a new image is pushed to the docker registry.
Additional context
Here are some logs showing that the image-updater is aware of the image but only seems to update one of the containers.
time="2020-08-27T09:59:05Z" level=info msg="Successfully updated image 'gcr.io/sopost-k8s/asfalia:v0.1.0-e46d4ba4a7ff398a387b28722332bb821cbf7129' to 'gcr.io/sopost-k8s/asfalia:v0.1.0-b5941f2ec8cb05590f1160bbae1a7ab25f943381'" application=ops-eu-asfalia image_name=sopost-k8s/asfalia image_tag=v0.1.0-e46d4ba4a7ff398a387b28722332bb821cbf7129 registry=gcr.io
time="2020-08-27T09:59:05Z" level=info msg="Processing results: applications=2 images_considered=3 images_updated=1 errors=0"
It would be helpful if in the log output, it showed the alias name too, so you know from the log which container would have been updated.
Version
v0.4.0
Logs
See above.
Also some images in the UI showing only the main image / tag was overridden:
Per the latest docs argocd-image-updater won't reuse Argo CD repo credentials for Git write-back. Is there a technical reason for the limitation, a security concern, or other? It would be great if users who understand the security implications could configure reuse and avoid adding another annotation to each Application definition.
Describe the bug
If you have a parameter in the Application, and there's a new image that's triggering an update of the Argo Application, it'll create an infinite sync loop.
To Reproduce
Add this to a Helm deployment's Application manifest:
spec:
source:
helm:
parameters:
- name: customVariable
value: customValue
Expected behavior
Should not be an infinite loop of sync.
Additional context
N/A
Version
v0.8.0 - sha256:e31a6c1dce2cfbe12b84f1a68b6e6c85f4ca227c32a6c5bab20e2dc053457e2e
Logs
N/A
Is your feature request related to a problem? Please describe.
Retrieving image tag meta data is an expensive task, depending on the latency of the registry's API. This can lead to a rather long cycle for the first update run, before the image cache is populated, confusing the interval setting.
Describe the solution you'd like
The image cache (which stores the meta data for tags) should be pre-filled before the first update cycle start, and also provide user feedback in the logs about the progress.
Is your feature request related to a problem? Please describe.
It looks like there is a lack of support for getting the API token required to authenticate against the ECR API. It would be great to be able to make use of the IAM Instance Profile assigned to a node which has GetAuthorizationToken
permissions. It might look similar to this: https://github.com/awslabs/amazon-ecr-credential-helper/blob/master/ecr-login/api/client.go.
Describe the solution you'd like
The image updater supports ECR authentication
Describe alternatives you've considered
There do not seem to be any alternatives without code changes.
Is your feature request related to a problem? Please describe.
We need to notify another systems when a version has changed and which is the new tag being used.
Describe the solution you'd like
I'd like to be able to monitor a kubernetes event containing at least:
This way we could add another piece to the pipeline to notify external services.
Describe alternatives you've considered
I've considered:
Additional context
By creating an event, other systems can take it to perform other different actions: notifications (email, slack, pagerduty, ...), maintain a dashboard, monitoring (grafana with tags showing the tag currently used), traceability (logs), ...
Describe the bug
When specifying the env var ARGOCD_SERVER
either via configmap or in the deployment directly, it does not actually perform an fqdn lookup for the correct IP address and uses the internal cluster service IP instead.
e.x.:
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/name: argocd-image-updater
app.kubernetes.io/part-of: argocd-image-updater
name: argocd-image-updater
spec:
revisionHistoryLimit: 0
selector:
matchLabels:
app.kubernetes.io/name: argocd-image-updater
template:
metadata:
labels:
app.kubernetes.io/name: argocd-image-updater
spec:
containers:
- command:
- /usr/local/bin/argocd-image-updater
- run
env:
- name: ARGOCD_GRPC_WEB
value: "true"
- name: ARGOCD_SERVER
value: "https://argo.mydomain.com"
time="2020-10-08T21:41:37Z" level=error msg="error while communicating with ArgoCD" argocd_server="https://argo.mydomain.com" grpc_web=true grpc_webroot= insecure=false plaintext=false
time="2020-10-08T21:41:37Z" level=error msg="Error: rpc error: code = Unknown desc = Post \"https://https//argo.mydomain.com
ineering/application.ApplicationService/List\": dial tcp: lookup https on 100.64.0.10:53: no such host"
To Reproduce
Provide an https URL in the ARGOCD_SERVER env var either via configmap or in the deployment directly
Expected behavior
Would expect the fqdn lookup to return the ingress IP and not the cluster local IP. When attempting to use the cluster local service (e.g. leaving ARGOCD_SERVER empty) it then tries to use https to the local pod:
time="2020-10-08T21:47:56Z" level=error msg="error while communicating with ArgoCD" argocd_server=argocd-server.argocd grpc_web=true grp
c_webroot= insecure=true plaintext=false
time="2020-10-08T21:47:56Z" level=error msg="Error: rpc error: code = Unknown desc = Post \"https://argocd-server.argocd:443/application
.ApplicationService/List\": read tcp 192.168.3.70:53584->192.168.0.17:8080: read: connection reset by peer"
This is with argocd-server
running with the --insecure
flag because if you try and run it without this flag, the error is then that the certificate it's using isn't valid.
Also, specifying INSECURE false vs. true in the argocd image updater seems to have no bearing on it's use of https:
time="2020-10-08T21:50:22Z" level=error msg="error while communicating with ArgoCD" argocd_server=argocd-server.argocd grpc_web=true grp
c_webroot= insecure=false plaintext=false
time="2020-10-08T21:50:22Z" level=error msg="Error: rpc error: code = Unknown desc = Post \"https://argocd-server.argocd:443/application
.ApplicationService/List\": read tcp 192.168.3.154:51664->192.168.1.64:8080: read: connection reset by peer"
Version
Argocd v1.7.6
Argocd image updater v.0.7.0
Describe the bug
The git push
fails if application source file is created by the image updater:
INFO[0003] git commit -a -m Update to new image versions dir=/var/folders/22/8kj96x2x5q735wjmcsjwb4lh0000gn/T/git-guestbook473645597 execID=xeAwD
ERRO[0003] `git commit -a -m Update to new image versions` failed exit status 1 execID=xeAwD
ERRO[0003] On branch image-updater
Your branch is up to date with 'origin/image-updater'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
kustomize-guestbook/.argocd-source-guestbook.yaml
nothing added to commit but untracked files present (use "git add" to track)
ERRO[0003] Could not update application spec: `git commit -a -m Update to new image versions` failed exit status 1 application=guestbook
To Reproduce
kustomize-guestbook
, downgrade image tag and configure write backExpected behavior
Image should be successfully updated
I have deployed an application in Argocd which uses image present in Docker hub container registry, when we update the image with new version in Docker Container Registry, Argocd Image updater should poll the Docker hub Container registry and update the application with latest verison of the image. This feature is not working.
Connection has been established between Argocd and Argocd Image updater, I can see in pod logs of Argocd Image updater,
Starting image update cycle, considering 1 annotated application(s) for update"
time="2020-11-17T09:16:05Z" level=info msg="Processing results: applications=1 images_considered=0 images_skipped=1 images_updated=0 errors=0"
I can see in logs its considering the application for update, but image is getting skipped, can't see any error logs and image is not getting updated for the application.
Logs:
time="2020-11-18T08:01:35Z" level=info msg="Starting health probe server TCP port=8080"
time="2020-11-18T08:01:35Z" level=info msg="Warming up image cache"
time="2020-11-18T08:01:35Z" level=info msg="Finished cache warm-up, pre-loaded 0 meta data entries from 5 registries"
time="2020-11-18T08:01:35Z" level=info msg="Starting image update cycle, considering 2 annotated application(s) for update"
time="2020-11-18T08:01:35Z" level=info msg="Processing results: applications=2 images_considered=0 images_skipped=2 images_updated=0 errors=0"
time="2020-11-18T08:03:35Z" level=info msg="Starting image update cycle, considering 2 annotated application(s) for update"
time="2020-11-18T08:03:35Z" level=info msg="Processing results: applications=2 images_considered=0 images_skipped=2 images_updated=0 errors=0"
time="2020-11-18T08:05:35Z" level=info msg="Starting image update cycle, considering 2 annotated application(s) for update"
time="2020-11-18T08:05:35Z" level=info msg="Processing results: applications=2 images_considered=0 images_skipped=2 images_updated=0 errors=0"
time="2020-11-18T08:07:35Z" level=info msg="Starting image update cycle, considering 2 annotated application(s) for update"
time="2020-11-18T08:07:35Z" level=info msg="Processing results: applications=2 images_considered=0 images_skipped=2 images_updated=0 errors=0"
time="2020-11-18T08:09:35Z" level=info msg="Starting image update cycle, considering 2 annotated application(s) for update"
time="2020-11-18T08:09:35Z" level=info msg="Processing results: applications=2 images_considered=0 images_skipped=2 images_updated=0 errors=0"
Registry.config looks like,
accounts.image-updater: apiKey
argocd.grpc_web: "true"
argocd.insecure: "true"
argocd.server_addr: 100.100.100.100
registries.conf: |
registries:
- name: Docker Hub
api_url: https://argocdhub.docker.io
ping: yes
credentials: secret:argocd-image-updater/secrets
defaultns: library
Any help/leads would be highly appreciated.
@jannfis , Could you please help with some leads on this.
Many Thanks!
I have a project with a newly published image. I can see the argo-image-updater registering the new arrival, and triggering an update. The update does not however go through.
Manually changing the app manifest in Argo does translate through to k8s though. So the connections
Argo-image-updater -> Repository and
Argo -> k8s
do work, it seems to be a problem with the connection
Argo-image-updater -> Argo.
Debug steps
I tried updating manually (editing the live manifest in the Argo UI), that went swimmingly (all pods deployed correctly).
I tried assigning full admin privileges to the argo-image-updater user in Argo, that did not change anything.
I restarted all pods in various configurations.
Logs
oc logs argocd-image-updater-<HASH>
time="2020-09-03T11:32:00Z" level=info msg="Processing results: applications=1 images_considered=1 images_updated=1 errors=0"
time="2020-09-03T11:34:00Z" level=debug msg="Starting image update process"
time="2020-09-03T11:34:00Z" level=debug msg="Considering 1 applications with annotations for update"
time="2020-09-03T11:34:00Z" level=debug msg="Processing application $APPLICATION"
time="2020-09-03T11:34:00Z" level=debug msg="Considering this image for update" application=$IMAGE image_name=$REPOSITORY/$IMAGE image_tag=2.1.0-dev.6 registry=$REGISTRY
time="2020-09-03T11:34:00Z" level=debug msg="Using version constraint '>=2.1.0-0' when looking for a new tag" application=$APPLICATION image_name=$REPOSITORY/$IMAGE image_tag=2.1.0-dev.6 registry=$REGISTRY
time="2020-09-03T11:34:00Z" level=debug msg="found 9 from 9 tags eligible for consideration" image="$REGISTRY/$REPOSITORY/$IMAGE:2.1.0-dev.6"
time="2020-09-03T11:34:00Z" level=info msg="Upgrading image to $REGISTRY/$REPOSITORY/$IMAGE:2.1.0-dev.102" application=$APPLICATION image_name=$REPOSITORY/$IMAGE image_tag=2.1.0-dev.6 registry=$REGISTRY
time="2020-09-03T11:34:00Z" level=debug msg="target parameters: image-spec= image-name=, image-tag=" application=$APPLICATION image=$REGISTRY/$REPOSITORY/$IMAGE
time="2020-09-03T11:34:02Z" level=info msg="Successfully updated image '$REGISTRY/$REPOSITORY/$IMAGE:2.1.0-dev.6' to '$REGISTRY/$REPOSITORY/$IMAGE:2.1.0-dev.102'" application=$APPLICATION image_name=$REPOSITORY/$IMAGE image_tag=2.1.0-dev.6 registry=$REGISTRY
time="2020-09-03T11:34:02Z" level=info msg="Processing results: applications=1 images_considered=1 images_updated=1 errors=0"
I believe the following of those lines hints at a problem:
time="2020-09-03T11:34:00Z" level=debug msg="target parameters: image-spec= image-name=, image-tag=" application=$APPLICATION image=$REGISTRY/$REPOSITORY/$IMAGE
oc logs argocd-server-<HASH>
time="2020-09-03T11:48:14Z" level=info msg="received unary call /application.ApplicationService/UpdateSpec" grpc.method=UpdateSpec grpc.request.claims="{\"iat\":1597138354,\"iss\":\"argocd\",\"jti\":\"image-updater\",\"nbf\":1597138354,\"sub\":\"image-updater\"}" grpc.request.content="name:\"$APPLICATIONt\" spec:<source:<repoURL:\"$HELM_SOURCE_ENDS_IN_.git\" path:\"$HELM_CHART\" targetRevision:\"HEAD\" helm:<releaseName:\"\" values:\"\" > chart:\"\" > destination:<server:\"https://kubernetes.default.svc\" namespace:\"$APPLICATION\" > project:\"$ARGO_PROJECT\" syncPolicy:<automated:<prune:false selfHeal:false > > > " grpc.service=application.ApplicationService grpc.start_time="2020-09-03T11:48:14Z" span.kind=server system=grpc
time="2020-09-03T11:48:15Z" level=info msg="image-updater updated application spec" application= $APPLICATIONdest-namespace=$APPLICATION dest-server="https://kubernetes.default.svc" reason=ResourceUpdated type=Normal
time="2020-09-03T11:48:15Z" level=info msg="finished unary call with code OK" grpc.code=OK grpc.method=UpdateSpec grpc.service=application.ApplicationService grpc.start_time="2020-09-03T11:48:14Z" grpc.time_ms=1171.407 span.kind=server system=grpc
Any ideas?
Describe the bug
With default configuration, metrics and heath can be accessed from both ports.
To Reproduce
Steps to reproduce the behavior:
INFO[0000] Starting health probe server TCP port=8080
INFO[0000] Starting metrics server on TCP port=8081
curl localhost:8080/metrics
, curl localhost:8081/metrics
, curl localhost:8080/healthz
and curl localhost:8081/healthz
to see that all of them worked.Expected behavior
curl localhost:8080/metrics
and curl localhost:8081/healthz
should fail.
Additional context
Version
0.8.0
Logs
Describe the bug
kubectl apply -k base/
install is failing on v0.3.1 because directories are listed in the resources
section. Should either move these directories to bases
or list each file individually.
To Reproduce
create base/kustomization.yaml with the following contents:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- github.com/argoproj-labs/argocd-image-updater/manifests/base/?ref=v0.3.1
run kubectl apply -k base/
Expected behavior
Manifests would be applied to the cluster
Additional context
The kustomization.yaml file is abbreviated and other resources relevant to our deployment have been omitted, but attempting install with both yields the same result.
Version
kubectl v1.18.6
kubernetes v1.17.9-eks-4c6976
Logs
$ kubectl apply -k base
error: AccumulateTarget: rawResources failed to read Resources: Load from path ./config failed: './config' must be a file (got d='/private/var/folders/pv/r1tbm8n92mx9t46kqx68bz6c0000gn/T/kustomize-669160585/manifests/base/config')
Is your feature request related to a problem? Please describe.
Currently, when multiple applications are referencing the same image, the available tags will be gathered from the container registry for each application that is referencing it. This results in unnecessary requests to the registries.
Describe the solution you'd like
We should implement a short living cache that stores available tags for each given image, so that further checks can just reuse that information. The cache should be dumped after each update check cycle.
Is your feature request related to a problem? Please describe.
ArgoCD supports a concept of Plugins, such as the kustomize/helm integration, and also used for extending ArgoCD for other use cases.
It appears that the argocd-image-updater only functions with the app.Status.SourceType is set to Kustomize
or Helm
(via auto-detect), and not when it is set to Plugin
.
Describe the solution you'd like
When the type Plugin is used, we could still implement Helm or Kustomize like-behavior for git-based workflows, whereas the image override file can be written back to git as if it were one of these two types.
Describe alternatives you've considered
Mainly it would be dropping the use of the plugin, but it has proven to be handy at times for pre-Sync instrumentation of service discovery.
Additional context
Relevant segment using the kustomized helm example:
resources:
- health:
status: Healthy
kind: Service
name: kustomize-release-name-helm-guestbook
namespace: default
status: Synced
version: v1
- group: apps
health:
status: Healthy
kind: Deployment
name: kustomize-release-name-helm-guestbook
namespace: default
status: Synced
version: v1
sourceType: Plugin
summary:
images:
- gcr.io/heptio-images/ks-guestbook-demo:0.2
I'm not 100% sure if this is an ArgoCD thing, argocd-image-updater, or sort of both for a feature such as this. I understand there's a lot of "if" there especially if it couldn't reconcile using the imperative updated to the Application resource itself.
Is your feature request related to a problem? Please describe.
Currently, to get the list of tags to consider for update, all tags returned by the registry for any given image are checked against the version constraint. This might result in the wrong image chosen for update.
Describe the solution you'd like
User should be able to pre-filter the list returned by the registry so that version constraints are checked only against a given set of tags. This could be implemented by an option such as argocd-image-updater.argoproj.io/<image_alias>.match-tags: <function>:<argument>
.
An example to match only tags whose name end with -foo
could look like follows (with a regexp
function):
argocd-image-updater.argoproj.io/<image_alias>.match-tags: regexp:.*-foo$
Describe the bug
The image updater does not seem to pull the latest image properly when using a Nexus image repository. I have enabled trace logs and have not been able to find any threads that would cause this. Looking at the code, it should dump out a list sorted by date and that list in the logs is definitely wrong. I am wondering if this is because creation metadata is buried in Nexus API.
To Reproduce
Steps to reproduce the behavior:
latest
update strategy. I do get different results using latest-last
and latest-first
sorting modes on the repository itself, which seems odd.Expected behavior
Latest image should be used
Version
v0.8.0+961de70
Is your feature request related to a problem? Please describe.
Currently, ArgoCD Image Updater only polls container registries for new tags at a given interval. Depending on the number of images and registries to be checked, this can lead to an overwhelming number of requests and takes a lot of time.
Describe the solution you'd like
Update checks for images should also be triggered asynchronously, i.e. by a webhook on image push to the registry.
Is your feature request related to a problem? Please describe.
I'm really excited to see argocd-image-updater repository as this feature is something I really felt I was missing our compared with flux and others like keel.sh. I've recently started using & migrating our application delivery process over to argocd and have really enjoyed seeing the development teams actually love the tool.
We have tagged images with the githash for a long time, and im sure many others have and will continue to do so. It's using the version tagging built into our version control tool of choice.. git. This is basically the only blocker to me trying out this tool.
Our current workflow is for devs to PR their new image githash, after mering their code the the respective branch. I want to make this process better.
Describe the solution you'd like
I would like to be able monitor for new version of my image tagged with a githash and auto deploy them, in the same way that this tool enables SemVer images to be deployed.
Describe alternatives you've considered
Additional context
I've dealt with this a little bit and will give some context to what I'm currently doing.
We use App of Apps for better or worse to manage all the applications in our environment. (Environment maps to a cluster which maps to a project in argocd) We are also using Declarative config from a single repository to define our ArgoCD application in yaml. Hence I have a tool (ansible) to generate the application config files, and also to regenerate them as needed.
One of the handy feature for me, it for ansible to go look at the applications git repository on a specified branch and return me the latest githash on that branch. That then feeds into my ArgoCD application yaml file that's generated. PR that to the ops repo and then the app of apps will sync it out.
I'd like in some way to replicate that back into the image-updater.
So perhaps to help with version constraints of githash'd images, we could look at using a git tag as a reference point.
For example maybe:
argocd-image-updater.argoproj.io/image-list: <image>:git+<git-ref>
# could be:
argocd-image-updater.argoproj.io/image-list: <image>:git+staging
# compared with the SemVer:
argocd-image-updater.argoproj.io/image-list: nginx:~1.26
The idea being:
new_hash
staging
referencenew_hash
in the commit history.A further check could compare the date of new_hash
with the existing hash
in the application. Update but warn if the image is older that the current hash.
This might be a nice pattern for allow updates based on git branches. Something we use but there are many other strategies.
A side benefit of having argocd talk the git, is that it could potentially know when a new commit is available and show that a deployment is incoming. I.e. the time between merge of code in the app's repo and the CI building & pushing the image to the container registry.
Sorry that's a lot of ideas that bring man challenges, so ...
Basic request
Stage 1 - Just deploy the latest githash tagged image when available, with respect to sync options (manual / auto).
Stage 2 - Think about how we can improve the experience with more safeguards, like restricting to a git branch.
Is your feature request related to a problem? Please describe.
GitHub has a new registry ghcr.io
, which is currently in beta. We should support it by out of the box, as we already support the docker.pkg.github.com
registry.
Is your feature request related to a problem? Please describe.
We need to find a proper way how we can synchronize our changes back to Git. Currently, we leverage Argo CD API to set the application parameters for image override, and Argo CD will update the Application resource with parameter overrides in the Kubernetes cluster. These changes need to be persisted somehow.
Describe the solution you'd like
I think the details about this need to be discussed and designed properly. This issue is open to collect all kind of ideas & discussions.
We would like to deploy the ArgoCD Image Updater - but in our environments, absolutely everything is declaratively deployed through kubernetes resources (Generally with Helm charts). I cannot see any way to declaratively create an authentication token for the image-updater in our ArgoCD system.
I really think that along the lines of #138, I consider the argocd-image-updater simply an additional component to the ArgoCD system.. so it should be able to be deployed along side ArgoCD and just leverage the various secrets and credentials that the ArgoCD system sets up already.
Describe the solution you'd like
Bypass token authentication and be able to install argocd-image-updater along side arogcd without any special work for authentication or authorization.
Describe the bug
ArgoCD image updater cannot find the login for a registry if https:// prefix is missing in secret. If prefix is added to secret it works fine.
To Reproduce
I login to a registry using
docker login ghcr.io
and use the resulting ~/.docker/config.json file to create a secret of type kubernetes.io/dockerconfigjson.
Then I start ArgoCD image updater and get the log:
time="2020-09-25T19:56:16Z" level=error msg="Could not set registry endpoint credentials: no valid auth entry for registry https://ghcr.io found in image pull secret ... registry=ghcr.io"
If the secret is created with docker login https://ghcr.io
it works fine.
Expected behavior
ArgoCD image updater should find the login even if https:// prefix is missing in secret.
Additional context
Version
v0.6.2
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.